CTCP Protocol

CTCP Version 1

Klaus Zeuge
Troy Rollo
Ben Mesander
May 1993

The Client-To-Client Protocol (CTCP)
Version One

Appendix A -- A description of the DCC protocol

By Troy Rollo (troy@plod.cbme.unsw.oz.au)
Revised by Ben Mesander (ben@gnu.ai.mit.edu)

Troy Rollo, the original implementor of the DCC protocol, said that the DCC protocol was never designed to be portable to clients other than IRCII. However, time has shown that DCC is useable in environments other than IRCII. IRC clients in diverse languages, such as ksh, elisp, C, and perl have all had DCC implementations.

Why DCC?

DCC allows the user to overcome some limitations of the IRC server network and to have a somewhat more secure chat connection while still in an IRC-oriented protocol.

DCC uses direct TCP connections between the clients taking part to carry data. There is no flood control, so packets can be sent at full speed, and there is no dependance on server links (or load imposed on them). In addition, since only the initial handshake for DCC conections is passed through the IRC network, it makes it harder for operators with cracked servers to spy on personal messages.

How?

The initial socket for a DCC connection is created by the side that initiates (Offers) the connection. This socket should be a TCP socket bound to INADDR_ANY, listening for connections.

The Initiating client, on creating the socket, should send its details to the target client using the CTCP command DCC. This command takes the form:

	DCC type argument address port [size]

type	 - The connection type.
argument - The connectin type dependant argument.
address	 - The host address of the initiator as an integer.
port	 - The port or the socket on which the initiator expects
	   to receive the connection.
size     - If the connection type is "SEND" (see below), then size
	   will indicate the size of the file being offered. Obsolete
	   IRCII clients do not send this, so be prepared if this is
	   not present.

The address, port, and size should be sent as ASCII representations of the decimal integer formed by converting the values to host byte order and treating them as an unsigned long, unsigned short, and unsigned long respectively.

Implementations of the DCC protocol should be prepared to accept further arguments in a CTCP DCC message. There has been some discussion of adding another argument that would specify the type of file being transferred - text, binary, and perhaps others if DCC is implemented on operating systems other than UNIX. If additional arguments are added to the protocol, they should have semantics such that clients which ignore them will interoperate with clients that don't in a sensible way.

The following DCC connection types are defined:

Type	Purpose					Argument
CHAT	To carry on a semi-secure conversation	the string "chat"
SEND	To send a file to the recipient		the file name

Although the following subcommand is included in the IRCII DCC command, it does _not_ transmit a DCC request via IRC, and thus is not discussed in this document: TALK Establishes a TALK connection

Implementation

The CHAT and SEND connection types should not be accepted automatically as this would create the potential for terrorism. Instead, they should notify the user that an offer has been made, and allow the user to accept it.

The recipient should have the opportunity to rename a file offered with the DCC SEND command prior to retrieving it. It is also desirable to ensure that the offered file will not overwrite an existing file.

Older IRCII clients send the entire pathname of the file being transmitted. This is annoying, and newer clients should simply send the filename portion of the file being transmitted.

The port number should be scrutinized - if the port number is in the UNIX reserved port range, the connection should only be accepted with caution.

If it is not possible in the client implementation language to handle a 32-bit integer (for instance emacs 18 elisp and ksh 88), then it is often possible to use the hostname in the originating PRIVMSG.

The following are the steps which should occur in the clients (this description assumes use of the BSD socket interface on a UNIX system).

Initiator:

DCC command issued.
Create a socket, bind it to INADDR_ANY, port 0, and make it passive (a listening socket).
Send the recipient a DCC request via CTCP supplying the address and port of the socket. (This is ideally taken from the address of the local side of the socket which is connected to a server. This is presumably the interface on the host which is closest to the rest of the net, and results in one less routing hop in the case of gateway nodes).

Continue normally until a connection is received.

On a connection:

Accept the connection.
Close the original passive socket.
Conduct transaction on the new socket.

Acceptor:

CTCP DCC request received.
Record information on the DCC request and notify the user.
At this point, the USER should be able to abort (close) the request, or accept it. The request should be accepted with a command specifying the sender, type, and argument, or a subset of these where no ambiguity exists.
If accepted, create a TCP socket.
Connect the new socket to the address and port supplied.
Conduct the transaction over the socket.

Type specific details.

CHAT

Data sent across a CHAT connection should be sent line-by-line without any prefixes or commands. A CHAT connection ends when one party issues the DCC CLOSE command to their clients, which causes the socket to be closed and the information on the connection to be discarded. The terminating character of each line is a newline character, '\n'.

FILE

Data is sent in packets, rather than dumped in a stream manner. This allows the DCC SEND connection to survive where an FTP connection might fail. The size of the packets is up to the client, and may be set by the user. Smaller packets result in a higher probability of survival over bad links. The recipient should acknowledge each packet by transmitting the total number of bytes received as an unsigned, 4 byte integer in network byte order. The sender should not continue to transmit until the recipient has acknowledged all data already transmitted. Additionally, the sender should not close the connection until the last byte has been acknowledged by the recipient.

Older IRCII clients do not send the file size of the file being transmitted via DCC. For those clients, note that it is not possible for the recipient to tell if the entire file has been received - only the sender has that information, although IRCII does not report it. Users generally verify the transfer by checking file sizes. Authors of clients are urged to use the size feature.

Note also that no provision is made for text translation.

The original block size used by IRCII was 1024. Other clients have adopted this. Note, however, that an implementation should accept any blocksize. IRCII currently allows a user-settable blocksize.

PREVIOUS PAGE | TABLE OF CONTENTS

Comments about this page? Send them to webmaster (at) invlogic.com.