Client-to-client protocol
Client-to-client protocol (CTCP) is a special type of communication between Internet Relay Chat (IRC) clients.
CTCP is a common protocol implemented by most major IRC clients in use today.[citation needed] CTCP extends the original IRC protocol by allowing users to query other clients or channels, this causes all the clients in the channel to reply the CTCP, for specific information. Additionally, CTCP can be used to encode messages that the raw IRC protocol would not allow to be sent over the link, such as messages containing newlines or the byte value 0 (NULL). CTCP does not establish a direct connection between clients; however, it is commonly used to negotiate DCC connections.
CTCP allows users to query a remote client about the version of the client they are using (via CTCP VERSION), or the time (via CTCP TIME), among other things. It is also used to implement the /me command (via CTCP ACTION).
History
ircII was the first IRC client to implement the CTCP and DCC protocols.[1] The CTCP protocol was implemented by Michael Sandrof in 1990 for ircII version 2.1,[2] while the DCC protocol was implemented by Troy Rollo in 1991 for version 2.1.2.[3]
Structure
A CTCP message is implemented as a PRIVMSG or NOTICE where the first and last characters of the message are ASCII value 0x01. Additionally, characters which would not be allowed in the IRC protocol are escaped. Since a NOTICE as the standard should not generate a reply, CTCP messages are sent as PRIVMSG and the reply is implemented with a NOTICE instead of a PRIVMSG.
A CTCP query is initiated on most clients as follows:
CTCP <target> <command> <arguments>
Where <target> is the target nickname or channel, <command> is the CTCP command (e.g. VERSION), and <arguments> are additional information to be sent to the <target>.
Common CTCP Commands
Please note that the following CTCP commands and replies are client-specific, however, are supported by the majority of IRC clients. Therefore, depending on your IRC client, you may or may not have an automated response (or replies) to specific incoming CTCPs set up, and these automated responses will differ between clients.
VERSION
A CTCP VERSION request will return the name and version of the IRC client the target is using, and in some cases technical information such as the operating system, clock rate, CPU Manufacturer and CPU architecture/instruction set.
A sample reply for a CTCP VERSION request to a target that uses the HexChat client (a fork of XChat) is:
VERSION HexChat 2.9.1 [x86] / Windows 8 [1.46GHz]
TIME
A CTCP TIME request will return the local time of the target computer. Depending on the IRC client, the reply may consist of the date, the time (either in 12-hour format or 24-hour format), the year (e.g. 2012), and sometimes the time zone (e.g. EST).
A sample reply for a CTCP TIME request to a target that uses the ChatZilla client is:
TIME Fri 23 Nov 2012 19:26:42 EST
PING
A CTCP PING request will determine the ping rate that directly exists between two clients (i.e. discounting the server). The CTCP PING command works by sending an (often) integer argument (a timestamp) to a target client, the target client then responds by supplying exactly the same numerical parameter. The difference between the original timestamp and the current timestamp is calculated, with the result being displayed to the user that initiated the CTCP PING. More often than not, a timestamp that utilises milliseconds is used due to the majority of users with broadband Internet connections having a ping under 1 second.
A sample CTCP PING request to target <nickname> from the XChat client is:
CTCP PING 23152511
Likewise, sample output generated from the difference (see above) is:
Ping reply from <nickname>: 0.53 second(s)
DCC
 | This article has multiple issues. Please help improve it or discuss these issues on the talk page. (Learn how and when to remove these messages)
|
Direct Client-to-Client (DCC) (originally Direct Client Connection[4][5][6]) is an IRC-related sub-protocol enabling peers to interconnect using an IRC server for handshaking in order to exchange files or perform non-relayed chats. Once established, a typical DCC session runs independently from the IRC server. Originally designed to be used with ircII it is now supported by many IRC clients. Some peer-to-peer clients on napster-protocol servers also have DCC send/get capability, including TekNap, SunshineUN and Lopster. A variation of the DCC protocol called SDCC (Secure Direct Client-to-Client), also known as DCC SCHAT supports encrypted connections. An RFC specification on the use of DCC does not exist.
DCC connections can be initiated in two different ways:
- The most common way is to use CTCP to initiate a DCC session. The CTCP is sent from one user, over the IRC network, to another user.
- Another way to initiate a DCC session is for the client to connect directly to the DCC server. Using this method, no traffic will go across the IRC network (the parties involved do not need to be connected to an IRC network in order to initiate the DCC connection).
See also
- Internet Relay Chat (IRC)
- IRC client
- Comparison of Internet Relay Chat clients
- DCC (Direct Client-to-Client)
References
- ^ Piccard, Paul; Brian Baskin; George Spillman; Marcus Sachs (May 1, 2005). "IRC Networks and Security". Securing IM and P2P Applications for the Enterprise (1st ed.). Syngress. p. 386. ISBN 1-59749-017-2.
The authors of the ircII software package originally pioneered file transfers over IRC.
- ^ See the 'NOTES' and 'source/ctcp.c' files included with ircii-2.1.4e.tar.gz[permanent dead link]
- ^ See the 'UPDATES' and 'source/dcc.c' files included with ircii-2.1.4e.tar.gz[permanent dead link]
- ^ "Open Source and Free Software". troy.rollo.name. Archived from the original on 2018-11-16. Retrieved 2018-11-15.
- ^ "DCC negotiation and connection". kvric.net.
- ^ "IRCHelp.org — The Client-To-Client Protocol (CTCP)". www.irchelp.org.