Some peer-to-peer clients on napster-protocol servers also have DCC send/get capability, including TekNap, SunshineUN and Lopster.
[5] The DCC protocol was implemented by Troy Rollo in 1991 for version 2.1.2,[6] but was never intended to be portable to other IRC clients.
Once a connection is established, the protocol used for DCC CHAT is very simple: users exchange CRLF-terminated messages.
The original specification for the handshake did not allow the receiver to know the total file size nor to resume a transfer.
It is common practice to add the file size as a last argument: DCC SEND filename ip port filesize.
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.
Another extension, TDCC, or turbo DCC, removes the acknowledgements, but requires a slightly modified handshake and is not widely supported.
The "DCC send exploit" can refer to two bugs: a variant buffer overflow error in mIRC triggered by filenames longer than 14 characters,[10] and an input validation error in some routers manufactured by Netgear, D-Link and Linksys, triggered by the use of port 0.
In the 2000s it was possible to combine multiple exploits into a single string, DCC SEND startkeylogger 0 0 0, which if posted in a public channel could cause multiple users to disconnect (either by crashing IRC clients, crashing routers, or triggering overly strict default settings in antivirus software).
[citation needed] 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.
The sender sends a CTCP offering a file to the receiver: DCC XMIT protocol ip port[ name[ size[ MIME-type]]] Square brackets here enclose optional parts.
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 beforehand.
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: This extension to normal DCC SEND and CHAT was introduced by the IRC client mIRC.
The sender offers a file to the receiver by sending the CTCP message: DCC REVERSE filename filesize key.
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, DCC REJECT REVERSE key.
This passive DCC mechanism is supported by at least mIRC, Visual IRC, HexChat, KVIrc, DMDirc, Klient, Konversation, and PhibianIRC.
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.