Direct Client to Client (DCC)

Written by Hammer & Merlin
Published with permission.

Table of Contents

  1. Introduction
  2. What is DCC?
  3. Why DCC?
  4. How does DCC work?
  5. The Implementation of DCC
  6. Type specific details
  7. What causes DCC problems
  8. Easy Fix
  9. Tia/Twinsock/Slipknot
  10. SLiRP
  11. Dynamic IP
  12. Static IP
  13. Windows Bugs
  14. Norton Desktop
  15. Long Filenames
  16. PROXY
  17. College/School/Work ISP
  18. Enhancing DCC Speeds
  19. DALnet specifics
  20. DCC Server
  21. XDCC/Fserve(File server)
  22. DCC Security

1. Introduction  Back to Top

This document has been previously released in the IRC Beginners Reference.
You can download this Reference as Helpfile. Just right click the link and choose Save As.

2. What is DCC?  Back to Top

DCC allows you to connect directly to another IRC client, instead of going through the IRC Network, to Send and Get files, and to Chat privately over a more secure connection.

By default, mIRC will pop up a dialog asking you if you want to accept the file, however if you select the Auto-Get file option then mIRC will automatically accept the file. If you select Ignore All then all incoming DCC send requests are ignored. If you choose to accept the file, mIRC will ask the sender to begin the file transfer, at which point you should begin receiving the file. If someone tries to send you a file that already exists in your get directory then you will be shown a warning that the file exists. You then have the option to either overwrite the file, resume the transfer, or rename the file. If you choose to overwrite the file then the whole file will be downloaded from the beginning and any existing file of the same name is erased. If you select resume then mIRC will attempt to negotiate a transfer resume to get the remaining part of the file.

3. Why DCC?  Back to Top

DCC allows the user to overcome some limitations of the IRC server network and to have the ultimate in secure chat connections 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 dependence on server links (or load imposed on them). In addition, since only the initial handshake for DCC connections is passed through the IRC network, it is impossible for Operators with cracked servers to spy on DCC messages.

4. How does DCC work  Back to Top

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:

Format: DCC <type> <argument> <address> <port>
The connection type
The connecting type dependant argument
The host address of the initiator as an integer
The port or the socket on which the initiator expects to receive the connection.

The address and port 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 and unsigned short respectively.

The following DCC connection types are known to IRCII:

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

In addition, the following are included in the IRCII DCC command, although they do not transmit a DCC request via IRC:

TALK = Establishes a TALK connection

5. The Implementation of DCC  Back to Top

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 send with the DCC SEND command prior to retrieving it.

The following are the steps which should occur in the clients:


  1. DCC command issued.
  2. Create a socket, bind it to INADDR_ANY, port 0, and make it passive (a listening socket).
  3. 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).

  4. Continue normally until a connection is received.

    On a connection:

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


  1. CTCP DCC request received.
  2. Record information on the DCC request and notify the user.
  3. 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.

  4. If accepted, create a TCP socket.
  5. Connect the new socket to the address and port supplied.
  6. Conduct the transaction over the socket.

6. Type specific details  Back to Top

The two types we explain here are CHAT and FILE.

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.


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.

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.

Note also that no provision is made for text translation.

The block size used by IRCII is BIG_BUFFER_SIZE (1024). This should probably be reviewed and reduced.

7. What causes DCC Send problems  Back to Top

There are many causes that can lead to DCC send errors, but to start out, you need to understand the basics. When you DCC someone, the following process takes place:

  1. You send a notice to the person sending to:
    -Yournick- DCC Send filename (YOURIPADDRESS)
  2. Their mIRC initiates a connection to YOURIPADDRESS
    If YOURIPADDRESS is incorrect, then the transfer will never take place - it's trying to goto an address that isn't assigned to you. Also if you are running any type of software (or your ISP is) that controls/monitors incoming connections, this may not allow the user to get through to you. This software is known as firewalls, proxies, wingates, ICS, and other multiple PC internet connection supporting software.

    This is also why you are able to receive but not send - think of the connection process backwards... when you send a file, the other user connects to you, when someone sends you a file, you are connecting to them.

8. Easy Fixes  Back to Top

Built into mIRC 5.71 and newer, is a command called /localinfo -uh. It's describe in the help file as:

/localinfo -uh [host ip]
Looks up and sets your local info settings. The -u switch performs a /userhost lookup, the -h switch does a normal lookup. If you wish, you can also set the local info manually by specifying the host and IP values.

Note: This process isn't flawless and doesn't always solve the problem, read on for more help.

If you see the message Unable to resolve Local host with the 32bit version of mIRC, the problem might be related to using a 16bit winsock, so you should try out the 16bit version of mIRC to see if it works for you (or download a 32bit winsock) at

If you type the command /localinfo -u mIRC will automatically fix an IP mismatch. Now wait, a common misconception is that you need to reconnect to IRC - and it's wrong.... you don't. Why not? Well we're just simply having mIRC correct your IP address that is used in the DCC send process. If you are afraid of typing new commands (like some preach to never type anything you don't understand fully), then you can use this method:

  1. Type: //echo 2 $ip
  2. Type: //dns $me
    You may not be able to get a reply to the DNS command, which means your address is numeric (and your names server is down). Simply compare your numeric address Yournick!identd@numericaddress with the //echo 2 $ip data. If the two numbers don't match press ALT E, goto the local info tab, put the resolved address in IP address block click on connect always get local host.
  3. Try to DCC Send a file to someone

Lastly, you need to make sure the person you're sending to has their mIRC setup... have them type /sreq and it should reply something along the lines of:
*** DCC Send requests pop up a dialog
*** DCC Send requests are auto-accepted
You do not want them to have:
*** DCC Send requests are ignored
If they have the ignore return, have them type /sreq ask. Then re-initiate the DCC send. On another note: It sounds stupid but a full hard disk very effectively blocks DCC getting files!

If none of this works for you, proceed to sections that might apply to the type of connection/software you are using. And remember, you should always have:

'On connect, Always get' Local Host and IP Address options in the Local_Info dialog checked
Set Lookup method to Normal.

If none of the other sections help you, you may try changing the lookup method to server. Make sure that your time-out values in DCC/Options are set large enough. "Get/Chat Dialog time out after" and "Send/Get Transfer time out after" are recommended to be set to at least 60 and 120, respectively.

With the Normal method, mIRC relies on your winsock to reply with the correct information. With the Server method, mIRC looks up your local host through the IRC Server, and then performs a /dns on it to resolve it to an IP address. The Server method will most likely be slower, you can tell when it has been completed when you see your local host name and IP address displayed in the status window. Note: If changing the above switches still doesn't solve the problem, or you don't know what to enter for your local host or IP address, contact your internet provider or system administrator.

9. TIA/Twinsock/Slipknot  Back to Top

If you use TIA (The Internet Adapter) or Twinsock, at this point you cannot use DCC send or initiate DCC chat (with any IRC client, not just mIRC). You may want to try SLiRP or vTCP. SLIRP was the first SLIP emulator to allow DCC sending and initiating DCC chat. (As you know DCC get should always work fine, whatever connection you have. Besides firewall blocking you that is.) Virtual TCP is tested and proofed to allow DCC sending and chatting.
More info and

10. SLiRP  Back to Top

With SLiRP set Tools/Options/Connect/Local_Info/ 'always get local host' on connect to Active, IP Address should be the fake IP used for SLiRP ( usually). Then DCC Send, Chat, and everything else should work perfectly fine, even on Windows95/98/2000 with the Dial-Up Networking.

11. Dynamic IP  Back to Top

If you have dynamic IP (your IP address is different each time you log on), make sure that "On connect, always get:" in the Tools/Options/Connect/Local_Info dialog is set to get the Local Host and IP Address. If these were already set to ON make sure the correct 'local host' name and 'IP Address' are found by mIRC... on some winsocks this is rather tricky... If you have a non-compliant stack, mIRC may not be able to correctly find your local host (domain name) and IP. With dynamic IP addressing you are in trouble then !! DCC file sending and initiating a DCC Chat (contrary to file getting and accepting a DCC Chat) requires that mIRC knows your correct IP number. Even without an IP number at all, mIRC will work as far as normal chatting is concerned, but won't allow DCC file sending or initiating a DCC Chat.

12. Static IP  Back to Top

If you have a non-compliant stack, mIRC may not be able to correctly find your local host (domain name) and IP. In the Tools/Options/Connect/Local_Info dialog, uncheck the options to "Always get the 'Local Host' and 'IP Address" and manually enter your correct Local Host and IP.

13. Windows Bugs  Back to Top

A known Windows95/98/2000 bug causes some people to report that mIRC (and any other IRC program) gets/finds the old (now wrong) Local Host name and/or IP Address after switching Internet provider. This blocks their capability of DCC Sending files and Initiating DCC Chats. If, for some reason, no matter what you do, mIRC picks the user ID (Local Host name) from the Internet Service Provider that you no longer wish to use this is fixable by editing the registry. If you open Regedit and look at MyComputer \HKEY_LOCAL_MACHINE \System \CurrentControlSet \Services \VxD \MSTCP you will see the Domain and NameServer fields from your old provider. These fields will persist even if you uninstall Dial-Up Networking and re-install and go through the TCP/IP settings again ! The best way to solve the described problem is going to Start/Settings/Control_Panel/Network/ double click on TCPIP/ select DNS_Configuration/ and set the HOST field to the hostname (ID) you have on your new provider.

14. Norton Desktop  Back to Top

Some people experience DCC File Send problems with mIRC on a windows system with Norton Desktop installed. mIRC then suddenly shuts down completely (sometimes with an error message) as soon as you try to select a file to send. The problem is that Norton Desktop's feature called 'File Assist' conflicts with mIRC's DCC Send dialog. If you shut off File Assist entirely it will allow DCC transfers fine. Even just disabling the "3D look and feel" in the File Assist options menu helps already.

15. Long Filenames  Back to Top

If you use Windows95/98/2000 mIRC allows you to send long file names with spaces in them, but other IRC programs very often cant handle this. This might cause your transfers to fail. You might want to select mIRC's option to fill (up) spaces in such a long file name by an underscore.

Another program known to give DCC Send problems is a software package called Long File Names by View software. It is something you might be running in the background and you might never think of it as the cause of your troubles. The problem is that when you use the DCC Send option in mIRC, the dialog that pops-up doesn't allow you to select files so you can't send anything. Selecting files is blocked by LFN and if you disable the LFN software all your DCC problems will be solved.

The DCC protocol doesn't take into account the possibility of a filename containing spaces, so most if not all IRC clients will incorrectly interpret the following DCC Send message:

PRIVMSG nick :DCC SEND This is a long file name with.spaces in it ipaddress port file size

Thus mIRC gives you the Fill Spaces option; this fills spaces in a filename with the underscore character _, which should then allow other clients to interpret the message correctly. So other clients would see:
PRIVMSG nick :DCC SEND This_is_a_long_file_name_with.spaces_in_it ipaddress port filesize

If the Fill Spaces option isn't selected then mIRC sends "Long File Names with.Spaces in them" enclosed in quotes. For example:

PRIVMSG nick :DCC SEND "This is a long file name with.spaces in it" ipaddress port filesize

As far as I know, only mIRC can send and receive messages of this form (and only versions 3.8 and onwards), so if you try using this dcc send message with other clients it probably won't work.

16. PROXY  Back to Top

As far as I understand it is totally impossible to get DCC Sending working when you're behind a proxy. You may try the DCC Server section.

17. College/School/Work ISP  Back to Top

Many mIRC users IRC from different places, but it's important for you to be aware that some network administators protect their server by not allowing incoming connections. This can be done with firewalls and such on the server side, and cannot be overridden by end users. Most suffer from not being able to DCC send, the only other option is to get the admin to allow incoming connections, or refer to the DCC server section.

18. Enhancing DCC Speeds  Back to Top

Packet Size

The packet size is the number of bytes that mIRC will send to another client in one packet. The minimum is 512, the maximum is 8192.
command: /dcc packetsize 8192

Note: Some sources indicate using 8192 as a packetsize may fragment your file.

Fill Spaces

The fill spaces option is only available in the 32bit version and only under operating systems that allow spaces in filenames. It is highly recommended that you leave this option turned on. For more information read this.
command: check Fill spaces after typing /dcc send

Fast Send

Turning on this option should speed up your DCC sessions.

command: /fsend on

Pump DCC

Basically it just sends N bytes ahead of sent data without waiting for the other client to reply "Acknowledged"

Since mIRC 5.7 you can only do /pdcc on | off, specifying a number makes no difference now. Nearly every user will never be able to send more than 25000 ahead, this is due to the limitations of current system mediums and bandwidth.

command: /pdcc on

Note: 99999999999 is just ignored


The faster the modem, the quicker the send - be aware that the send steps down to the speed of the slowest modem in use.

19. DALnet Specifics  Back to Top

A new system that prevents the spread of executable or dangerous scripts without the permission of the user receiving them. The DCCALLOW system prevents transmission of "exe", "com", "bat", "dll", "ini", "vbs", "pif", "mrc", "scr", "doc", "xls", "lnk", "shs", "js" and "pl".
Command specifics:

/DCCALLOW [<+|->nick[,<+|->nick, ...]] [list] [help]

You would see a message like this (if trying to send a file of this type):

The user Somenickname is not accepting DCC sends of filetype *.EXE from you. Your file filename.exe was not sent.

And Somenickname would receive:

-Servername- Yournickname (address) has attempted to send you a file named filename.EXE, which was blocked.

-Servername- The majority of files sent of this type are malicious virii and trojan horses. In order to prevent the spread of this problem, we are blocking DCC sends of these types of files by default.

If you completely trust this person, you would type /dccallow +nickname and you will see:

nickname has been added to your DCC allow list

After you have finished your file transfer, it is wise to remove them from the list, by typing /dccallow -nickname and you will see:

nickname has been removed from your DCC allow list

You may list your allowed users by typing:

/dccallow list

You will receive:

The following users are on your dcc allow list:

nickname (address)

End of DCCALLOW list

20. DCC Server  Back to Top

This is how you can bypass the reverse method of DCC. The receiving user must have DCC server on and listening for the appropriate type of DCC you intend on sending.

/dccserver [+|-scf] [on|off] [port]

example:/dccserver +scf on 59

The mIRC DCC Server listens for direct connections to your IP address from other mIRC clients. In options (alt D, o) , you can set the following:

Enable DCC Server

This turns the DCC Server on or off.

Listen on Port
The DCC Server listens on port 59 by default, however you can change this to another port number.

Listen for...

You can have the DCC Server listen for only certain types of connections, such as DCC Sends, Chats, or File server requests. For example, if you turn off the DCC Chat listen option, the DCC Server will ignore any chat requests.

Perform DNS lookup

When someone connects to your DCC Server only their IP address is available for identification. If you check the DNS lookup switch, mIRC will perform a /dns on the IP address to try to resolve it to a named address. Note: It can take anything from a second to more than minute to resolve an address depending on network conditions, and sometimes it may not resolve at all. You can Send/Chat to the DCC Server using the DCC Send/Chat dialogs and specifying an IP address instead of a nickname.

To send, you use an IP address instead of a nickname to initiate a connection

/dcc [send|chat|fserve] IPADDRESS:PORT

The IP address can be numeric or alphanumeric, to obtain this data do a whois on the person you want to send the file to. You will see the following (unless you are using a script that filters this data differently):

nickname is user@host * "a fancy saying"

nickname on #somechannel

nickname using someserver@somenetwork "a fancy saying"

nickname End of /WHOIS list.

The first line is what we are concerned with. See the user@host part? the host section (whatever is after @) is where you are going to DCC to. You'll want to use whatever port they have setup when they enabled their DCC server. To send a file to the user, type:

/dcc send host:port

example: /dcc send (this is alphanumeric)

example: /dcc send 100.200.300.4:59 (this is numeric)

Note: Either host type is just as efficient as the other. /dcc fserve only works for IP address connections and does not work via IRC.

21. XDCC/Fserve  Back to Top

As a lot of people on IRC promote and share the best they found around on the net, mIRC now offers a unique built-in File server. This File server feature is somewhat of a cross between DCC and FTP. You open the server window to someone, (it's a special DCC chat window), restricting them to a certain directory tree, and they can browse your file listings, change directories, read text files, or get files.

The syntax to set up a DCC server connection to somebody is:

/fserve <nick> <max gets simultaneously allowed> <homedir> [welcome file]

"Max gets" is so that the other person doesn't bring down your machine with too many parallel gets. 4 is probably a reasonable number. The other person will have access to his homedir and all dirs DOWN in the directory tree from that homedir on. "Welcome file" is a text file you can write and specify that will welcome users to your file server. It's optional.


/fserve Krejt 3 c:\temp\serve c:\temp\serving\welcome.txt

/fserve Mookies 2 c:\outgoing c:\network\mirc\welcome.txt

/fserve Friend 7 c:\

Keep in mind that you can't set up a server to yourself... you need others to test your server...

Typing help in the file server will show the available commands, which are styled after Unix and DOS. "ls" or "dir" will show a directory listing, for example. Even switched commands like "ls -k" (show file sizes in kilobytes) and "dir /w" (show a wide directory listing) work. The server supports all normal ftp commands like cd <dir> , cd.., dir, ls, get, .... but NOT put, hash, upload etc. There is no possibility to delete files in a server connection. Safety risks are none or minimal due to the major restricting of available commands.

Of course, the /fserve command can be used in your Remote section....
Set up a simple Tools/Remote/command like :

ctcp 1:server:/fserve $nick 3 c:\temp\serve

Set the commands to active (/remote on) and off you go....

Other people only have to type "/ctcp yournick server" to activate the server. You can't set up a server to your own mIRC!! So, others have to test your server !! In the directory c:\temp\serve, you place all files other people are allowed to get from you. The people using your server will have access to the c:\temp\serve directory AND ALL directories BELOW it.. like c:\temp\serve\games.

22. DCC Security  Back to Top

NEVER NEVER NEVER accept a DCC chat or file send from someone you do not know or trust!!!

This is the cause of 95% of all IRC security problems. In the mIRC DCC options section, set DCC Chat and Send to "ASK". Never have the Auto Get option checked

In short; Trojan horse attacks are attractively disguised files that you download and run, resulting in harmful and dangerous consequences ranging from takeover of your IRC channels, erasing of your hard disk, theft of your account passwords, etc. These (Trojan) viruses are not mIRC or IRC specific, they just spread like fire on IRC.

Trojans are typically files with suffices like "ini", "exe", or "com", such as "dmsetup.exe" or "script.ini". These days nearly all trojans are spread in the guise of a free game, handy tool or other software. You probably downloaded one from a WWW or FTP archive, ICQ file exchange, or through IRC's DCC file transfer (by manual /dcc get or, even worse, an "auto DCC get" feature which allows anybody to send you anything, including not only trojans but also other viruses, child porn, etc).

Typically the Trojan needs to be run manually at first (by you), and then installs hacked files all over your disk silently. There are many different versions of those files, but almost all of them interfere with your mIRC placing backdoors in scripts. The files then auto-send themselves (using an 'ON JOIN' event) to everyone who joins the same channel as an infected user without the users knowledge.

On DALnet is a channel specifically for helping users with virii/trojan help. It's called #Nohack you can get there by clicking here. If you're not on DALnet and the above link doesn't help, in mIRC type /server and once connected type join #nohack. Or you can goto

At you will find detailed instructions and information on all kinds of problems you may encounter on IRC. At this site the best help for problems like this is concentrated and organized by people who are on IRC 24/7, in the Help channels and alike. Read to learn all about the viruses on IRC, mostly called Worms or Trojans, that might tackle you.

Prevention: NEVER download files from people or sites which you aren't 100% sure about. Never use the "auto DCC get" feature, and always scan your DCC gets with a decent virus scanner. Note that mIRC by default does NOT accept files from strangers. This has never been otherwise either. If you accepted files by the "auto DCC get" feature in mIRC, you have switched this option ON yourself, really. Do not, never ever, accept anything you have not requested. Do not accept anything from someone you don't know, no matter how attractively packaged.