Direct Client-to-Client (DCC) 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. Internet Relay Chat (IRC) is a form of instant communication over the Internet. ... A peer-to-peer (or P2P) computer network is a network that relies on the computing power and bandwidth of the participants in the network rather than concentrating it in a relatively few servers. ... In telecommunication and microprocessor systems, the term handshaking has the following meanings: In data communications, a sequence of events governed by hardware or software, requiring mutual agreement of the state of the operational modes prior to information exchange. ... The title given to this article is incorrect due to technical limitations. ... In computing, a client is a system that accesses a (remote) service on another computer by some kind of network. ...

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 DCC).

CTCP stands for Client-To-Client-Protocol, which is a special type of communication between Internet Relay Chat (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 (the message is still in plaintext, though).

DCC CHAT is normally initiated using a CTCP handshake. The user wishing to establish the connection sends the following CTCP to the target, CTCP stands for Client-To-Client-Protocol, which is a special type of communication between Internet Relay Chat (IRC) Clients. ...

 DCC CHAT <protocol> <ip> <port> 

where <ip> and <port> are those of the sender, and are expressed as integers. <protocol> is "chat" for standard DCC CHAT. The receiving party can then connect to the given port and 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 ^A) and the word "ACTION", and are optionally terminated by another ASCII 001, are interpreted as emotes: CRLF is a sequence of control characters consisting of a carriage return (CR) and a line feed (LF). ... For other uses, see ASCII (disambiguation). ...

 ^AACTION waves goodbye^A 

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 pseudo-filename "chat" replaced by "wboard":

 DCC CHAT wboard <ip> <port> 

Once the connection is established, the two clients exchange CRLF-terminated messages. Messages that begin (and optionally end) with ASCII 001 are interpreted as special commands; the command ACTION 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. CRLF is a sequence of control characters consisting of a carriage return (CR) and a line feed (LF). ...

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 <filename> <ip> <port> 

As with DCC CHAT, <ip> and <port> are the ip address and port where the sending machine will be listening for an incoming connection. It is common practice to add the file size as a last argument:

 DCC SEND <filename> <ip> <port> <file size> 

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 <filename> <port> <position> 

If the sending client supports DCC RESUME, it will reply with

 DCC ACCEPT <filename> <port> <position> 

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 in blocks, which the client must acknowledge by sending sizes of incoming data blocks as 32-bit network byte order integers. This slows down connections, and is redundant because such behavior is already implemented by 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. 32-bit is a term applied to processors, and computer architectures which manipulate the address and data in 32-bit chunks. ... When integers or any other data are represented with multiple bytes, there is no unique way of ordering of those bytes in memory or in a transmission over some medium, and so the order is subject to arbitrary convention. ... The Transmission Control Protocol (TCP) is one of the core protocols of the Internet protocol suite. ...

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 "T" after the handshake, making this version of TSEND compatible with other clients (as long as they can parse the modified handshake).

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: CTCP stands for Client-To-Client-Protocol, which is a special type of communication between Internet Relay Chat (IRC) Clients. ...

 DCC XMIT <protocol> <ip> <port>[ <name>[ <size> [<MIME-type>]]] 

Square brackets here enclose optional parts. <protocol> is the protocol to use for the transfer; only "clear" is defined presently. Unlike standard DCC SEND, <ip> can be in the additional forms of standard dotted notation for IPv4, or either hexadecimal or mixed notation for IPv6. To leave an early parameter empty, but still supply a later one, the earlier one can be specified as "-". If the receiver does not implement the protocol used, it will send back a CTCP reply of the format: In computing, a protocol is a convention or standard that controls or enables the connection, communication, and data transfer between two computing endpoints. ...

 ERRMSG DCC CHAT <protocol> unavailable 

CHAT is used here to maintain compatibility with the error messages sent by the extended DCC CHAT. If the receiver declines the transfer, it sends the following CTCP reply:

 ERRMSG DCC CHAT <protocol> declined 

Other errors are reported in the same fashion. If the receiver is willing and capable of receiving the file, it will connect to the given address and port. What happens then depends on the protocol used.

In the case of the "clear" protocol, the XMIT server will, upon receiving a connection, send a 32-bit time_t in network byte order, representing the file's modification time. Presumably based on the modification time of the local file, the client will then send another network byte order long, an offset which the server should seek to when sending the file. This should be set to zero if the whole file is wanted, or the size of the local file if the client wishes to resume a previous download. Unix time, or POSIX time, is a system for describing points in time. ... When integers or any other data are represented with multiple bytes, there is no unique way of ordering of those bytes in memory or in a transmission over some medium, and so the order is subject to arbitrary convention. ... Endianness generally refers to sequencing methods used in a one-dimensional system (such as writing or computer memory). ... In computer science, an offset within an array or other data structure object is an integer indicating the distance (displacement) from the beginning of the object up until a given element or point, presumably within the same object. ...

While faster than SEND, XMIT carries one of the same limitations in that it is impossible to tell how big the file is, unless its size is specified in the CTCP negotiation or known before hand. Furthermore, you can not resume a file past the two gigabyte mark due to the 32-bit offset. CTCP stands for Client-To-Client-Protocol, which is a special type of communication between Internet Relay Chat (IRC) Clients. ...

Passive DCC

In a normal DCC connection the initiator acts as the server, and the target is the client. Because of widespread firewalling and reduction of end-to-end transparency because of NAT, the initiator might not be able to act as a server. Various ways of asking the target to act as the server have been devised: For articles that discuss specific cases of connection and other usages of the term see Connection (disambiguation). ... In computing, a server is a software application that carries out some task (i. ... The term client may have the following meanings. ... In computing, a firewall is a piece of hardware and/or software which functions in a networked environment to prevent some communications forbidden by the security policy, analogous to the function of firewalls in building construction. ... In computer networking, the process of network address translation (NAT, also known as network masquerading or IP-masquerading) involves re-writing the source and/or destination addresses of IP packets as they pass through a router or firewall. ...

DCC Server

This extension to normal DCC SEND and CHAT was introduced by the IRC client mIRC. DCC Server has moderate support, but is not standard on all clients (see comparison of IRC clients). The target and initiator must somehow agree on a port to use, which the target then listens on. A handshake then takes place: mIRC is a shareware Internet Relay Chat client for Windows, created in 1995 and developed by Khaled Mardam-Bey. ... This is a comparison of Internet Relay Chat clients. ...

For a CHAT, the initiator sends:

 100 <initiator nick> 

The target then replies with

 101 <target nick> 

and the rest proceeds according to standard DCC CHAT protocol.

For a SEND, the initiator sends:

 120 <initiator nick> <filesize> <filename> 

The target replies with:

 121 <target nick> <resume position> 

where <resume position> is the offset in the file from which to start. From here the transfer proceeds as a normal DCC SEND.

DCC Server also supports mIRC-style file servers and DCC GET.

RDCC

DCC Server provides no way specifying the port to use, so this has to be negotiated manually, which is not always possible, as one of the sides may not be a human. RDCC is a handshake mechanism for DCC Server, which in addition to the port also provides the ip address of the server, which the client might not be able to find otherwise because of host masking. It is not widely supported.

The initiator requests the port the target is listening on by sending the CTCP query:

 RDCC <function> <comment> 

where <function> is 'c' for chat, 's' for send and 'f' for file server. The target may then CTCP reply with:

 RDCC 0 <ip> <port> 

where <ip> and <port> have the same meanings as for normal DCC SEND and CHAT. After this the initiator connects to the ip and port, and a DCC Server handshake follows.

DCC REVERSE

Unlike DCC Server, where the handshake is handled over the DCC connection, DCC REVERSE has a normal CTCP handshake, similar to the one used by DCC SEND. This is not widely implemented. The sender offers a file to the receiver by sending the CTCP message:

 DCC REVERSE <filename> <filesize> <key> 

<key> is a 1 to 50 characters long string of ASCII characters in the range 33 to 126, and acts as an identifier for the transfer. If the receiver accepts, it sends the CTCP reply For other uses, see ASCII (disambiguation). ...

 DCC REVERSE <key> <start> <ip> <port> 

Here <start> is the position in the file from which to start sending, <ip> is the IP address of the receiver in standard dotted notation for IPv4, or hexadecimal notation for IPv6. The sender then connects to the ip address and port indicated by the receiver, and a normal DCC SEND follows. Both the sender and receiver can cancel the handshake by sending the CTCP reply In computer networking, an IP address (internet protocol address) is a unique number that devices use in order to identify and communicate with each other on a network utilizing the Internet Protocol standard. ... Dot-decimal notation is a method of expressing octets using base-10 rather than hexadecimal. ... IPv4 is version 4 of the Internet Protocol (IP). ... In mathematics and computer science, hexadecimal, or simply hex, is a numeral system with a radix or base of 16 usually written using the symbols 0–9 and A–F or a–f. ... Internet Protocol version 6 (IPv6) is a network layer standard used by electronic devices to exchange data across a packet-switched internetwork. ...

 DCC REJECT REVERSE <key> 

DCC RSEND

This is the KVIrc client's alternative to DCC REVERSE. The sender offers a file by sending the CTCP A screenshot of KVIrc in use on Gnome under Debian Linux. ...

 DCC RSEND <filename> <filesize> 

The receiver can then accept by CTCP replying with

 DCC RECV <filename> <ip> <port> <start> 

and the sender connects to the receiver and sends as during a normal DCC SEND.

Reverse / Firewall DCC

This passive DCC mechanism is supported by mIRC and Visual IRC. The sender offers a file by sending the CTCP message: mIRC is a shareware Internet Relay Chat client for Windows, created in 1995 and developed by Khaled Mardam-Bey. ... Visual IRC (ViRC) is an open source Internet Relay Chat client for the Windows operating system. ...

 DCC SEND <filename> <ip> 0 <filesize> <token> 

<ip> is the IP address of the sender in network byte order, expressed as a single integer (as in standard DCC). The number 0 is sent instead of a valid port, signaling that this is a Reverse DCC request. <token> is a unique integer; if TSEND is being used (by a client that supports it), the letter "T" is appended to the token, letting the receiver know it doesn't need to send acknowledgements. In computer networking, an IP address (internet protocol address) is a unique number that devices use in order to identify and communicate with each other on a network utilizing the Internet Protocol standard. ...

The receiver can accept the file by opening a listening socket and responding with the CTCP message:

 DCC SEND <filename> <ip> <port> <filesize> <token> 

This is identical to the original Reverse DCC message, except the <ip> and <port> identify the socket where the receiver is listening. <token> is the same as in the original request, letting the sender know which request is being accepted. (Since this message follows the same format as a regular DCC send request, some servers which filter DCC requests may require the sender to add the receiver to his or her "DCC allow" list.)

The sender then connects to the receiver's socket, sends the content of the file, and waits for the receiver to close the socket when the file is finished.

File servers (FSERVs)

A DCC fserve, or file server, lets a user browse, read and download files located on a DCC server.

Typically, this is implemented with a DCC CHAT session (which presents the user with a command prompt) or special CTCP commands to request a file. The files are sent over DCC SEND or DCC XMIT. There are many implementations of DCC file servers, among them is the FSERV command in the popular mIRC client. CTCP stands for Client-To-Client-Protocol, which is a special type of communication between Internet Relay Chat (IRC) Clients. ... mIRC is a shareware Internet Relay Chat client for Windows, created in 1995 and developed by Khaled Mardam-Bey. ...

See also

• Secure Direct Client-to-Client
• XDCC

This article does not cite its references or sources. ... XDCC (Xabi DCC or eXtended DCC) was initially a script written in 1994 for ircII by Xabi. ...

External links

• A description of the DCC protocol (note: Most IRC-clients and networks have implemented extensions to the DCC protocol. The DCC commonly used today has evolved quite a bit from what this document describes. A successor to DCC (DCC2) is currently being formalized by DCC2.org)
• DCC negotiation and connection
• A description of the Turbo DCC protocol
• A description of the DCC Whiteboard protocol