Requirements 
 License 

 Installation 
 IRC usage 
 Server connects 
 DCC sends 
 Logging 

 Format 
 Reference 
 Example 

 Roadmap 
 Download 
 Config parser 
 Visions & ideas 

DCC sends

MetalServe's DCC send system and the available configuration directives may be confusing at first, which is why the topic deserves an extra explanation:

• there is a certain number of send slots, each of which is assigned to the ongoing transfer of a specific file.

  Send slots are divided in those for the transfer of filelists, whose number can be set using the dcc_maxlistxfers configuration direction, and those for the transfer of "ordinary" files, whose number can be set using the dcc_maxxfers configuration directive. So in total you will actually have at most

  (dcc_maxxfers + dcc_maxlistxfers)

  parallel DCC transfers at a given time.

  Remember that filelists are requested differently than ordinary files by the user (see the IRC usage page).

• there is a limit as to the number of send slots for "ordinary" files that can be occupied by a single user. This limit can be set using the dcc_maxuserxfers configuration directive.

  There is no need for a limit for the filelist send slots since each user can request and receive the filelist only once at any given time.

• when there are not enough send slots to satisfy an incoming request, the request is queued, ie. it is put into a FIFO (first-in, first-out) queue, where it will be picked up from as soon as a send slot becomes available.

  As with the send slots, there is a distinction between filelists and "ordinary" files. There are two seperate queues for these for which the following rules apply:

  1. the size of the (ordinary) file request queue can be set using the dcc_maxqueue configuration directive. Additionally, the number of files that can be requested by a specific user is restricted by the dcc_maxuserqueue directive.

  2. the size of the filelist request queue can be set using the dcc_maxlistqueue configuration directive. Each user can only have one request within this queue since there is only one filelist they can request.

• a queued request for an ordinary file is taken from the (ordinary) file request queue and satisfied as soon as:
  1. one of the dcc_maxxfers send slots becomes available, and

  2. the user has less than dcc_maxuserxfers transfers in progress. If he does, a different user's request will be satisfied.

• a queued request for the filelist is taken from the filelist queue and satisfied as soon as one of the dcc_maxlistxfers send slots becomes available.

• dcc_maxuserxfers < dcc_maxxfers
• dcc_maxuserqueue < dcc_maxqueue

Besides these "hard" limits, the following considerations should be taken into account when specifying custom values:

• Adjusting the dcc_maxxfers value only affects how your available bandwidth is divided among your clients: the more sends you allow at the same time, the less bandwidth remains for each client, and you should not expect your clients to accept DCC sends with unbearable low download speeds.

  Based on the author's opinion that an effective download speed below 4 KB/s nowadays is unacceptable, he recommends the following values:

  Send speed	Max. xfers
  < 8 KB/s	1
  8-16 KB/s	1-2
  16-50 KB/s	2-3
  > 50 KB/s	4 and more

  The default value of two concurrent sends was chosen to accomodate typical German DSL customers, who have a send speed of 128 Kbit/s.

• The dcc_maxxfers value determines how many requests can be satisfied at the same time, and thus also how fast the request queue can be processed.

• A too small queue length will piss off users since your server will seem to be desperately overloaded and users have no chance to request files. A too long queue length will leave your users waiting for ages when they probably should have been told to try again at a different time instead.

• Varying the queue length has no impact on system resources, so you can choose a long queue length (around 100) if you have sufficient bandwidth (more than 1 MBit/s) so that your clients are served quickly and the effective time to wait does not become unbearable.