Direct Client-to-Client

Direct Client-to-Client (DCC) (originally Direct Client Connection) 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).

History

ircII was the first IRC client to implement the CTCP and DCC protocols. The CTCP protocol was implemented by Michael Sandrof in 1990 for ircII version 2.1. The DCC protocol was implemented by Troy Rollo in 1991 for version 2.1.2, but was never intended to be portable to other IRC clients.

Common DCC applications

DCC CHAT

The CHAT service enables users to chat with each other over a DCC connection. The traffic will go directly between the users, and not over the IRC network. When compared to sending messages normally, this reduces IRC network load, allows sending of larger amounts of text at once, due to the lack of flood control, and makes the communication more secure by not exposing the message to the IRC servers (however, the message is still in plaintext).

DCC CHAT is normally initiated using a CTCP handshake. The user wishing to establish the connection sends the following CTCP to the target, DCC CHAT , where and are the IP address and port number of the sender, and are expressed as integers. is for standard DCC CHAT. The receiving party can then connect to the given port and IP address.

Once a connection is established, the protocol used for DCC CHAT is very simple: users exchange CRLF-terminated messages. Messages that begin with an ASCII 001 (control-A, represented below by ) and the word , and are terminated by another ASCII , are interpreted as emotes: ACTION waves goodbye A/code>.


DCC Whiteboard

This is an extension to DCC CHAT, allowing simple drawing commands to be sent as well as lines of text. DCC Whiteboard is initiated with a handshake similar to DCC CHAT, with the protocol replaced by :
DCC CHAT wboard .

Once the connection is established, the two clients exchange CRLF-terminated messages. Messages that begin (and optionally end) with ASCII are interpreted as special commands; the command represents an emote, while others cause lines to be drawn on the user's whiteboard surface, or allow the two clients to negotiate a set of features.

DCC SEND

The SEND service allows users to send files to one another. The original specification for the handshake did not allow the receiver to know the total file size nor to resume a transfer. This has made clients introduce their own extensions to the handshake, many of which have become widely supported.

The original handshake consisted of the sender sending the following CTCP to the receiver: DCC SEND .

As with DCC CHAT, and are the IP address and port where the sending machine will be listening for an incoming connection. Some clients enclose filenames with spaces in double quotes. It is common practice to add the file size as a last argument: DCC SEND .

At this point, the original specification had the receiver either connect to the given address and port and wait for data, or ignore the request, but for clients supporting the DCC RESUME extension, a third alternative is to ask the sender to skip part of the file by sending the CTCP reply: DCC RESUME .

If the sending client supports DCC RESUME, it will reply with, DCC ACCEPT , and the receiver can connect to the given address and port and listen for data to append to an already existing file.

Data is sent to the client in blocks, each of which the client must acknowledge by sending the total number of bytes received in the form of a 32-bit network byte order integer. This slows down connections and is redundant because of TCP. The send-ahead extension relieves this problem somewhat by not waiting for the acknowledgements, but since the receiver still has to send them for every block it receives, in case the sender expects them, it is not solved completely.

Another extension, TDCC, or turbo DCC, removes the acknowledgements, but requires a slightly modified handshake and is not widely supported. Older versions of TDCC replaced the word SEND in the handshake with TSEND; later versions use the word SEND but append a after the handshake, making this version of TSEND compatible with other clients (as long as they can parse the modified handshake).

DCC SEND exploit

The DCC send exploit can refer to two bugs, a variant buffer overflow error in mIRC triggered by filenames longer than 14 characters and an input validation error in some routers manufactured by Netgear, D-Link and Linksys, triggered by the use of port . The router exploit, in particular, may be triggered when the phrase '' followed by at least 6 characters without spaces or newlines appears anywhere in a TCP stream on port 6667, not just when an actual DCC SEND request has been made.

DCC XMIT

The XMIT service is a modified version of DCC SEND that allows for resuming files and cuts down on wasteful traffic from the ACK longs. XMIT is not widely supported.

The XMIT handshake differs somewhat from the SEND handshake. The sender sends a CTCP offering a file to the receiver: DCC XMIT [_[_.html"_;"title="[_.html"_;"title="[_[_">[_[_">[_.html"_;"title="[_[_">[_[_/code>

Square_brackets_here_enclose_optional_parts.__is_the_protocol_(computing).html" "title=".html"_;"title="[_[_">[_[_.html" ;"title="[_.html" ;"title="[ [ ">[ [ ">[_.html" ;"title="[ [ ">[ [ /code>

Square brackets here enclose optional parts. is the protocol (computing)">protocol