Max upload slots
Intro
Roughly, that's the maximum number of peers that will be served with shared files at once. As pango says
- Each shared directory with reserved slots (with the share command) will get them (unless there's really so little demand that no peer takes them).
- Then, if the total of upload slots is less than max_upload_slots, additionnal non-reserved slots will be allocated for incoming, shared directories with no reserved slots (priority = 0), and files being downloaded (There's an incoming_directory_prio setting, so theoretically you could also reserve slots for incoming, but I think it's currently broken)._
- You can also set dynamic_slots, so additionnal non-reserved slots will only be allocated if the uplink isn't fully used (another way to try to keep the number of upload slots low whenever possible).
from pango tuning howto:
- Allocating more bandwidth per uploader is good for file propagation. For the maximum number of uploaders at a time, eMule uses upload_rate / 3Kb, so 10 slots should be ok for uplinks up to 256kbps by the same reasoning (but servicing few uploaders at a time is still controversial, because the official client tried such path during v58 and v59, and had to step back)
How MLdonkey allocates upload slots
It seems that when MLdonkey allocates upload slots, a random client is picked in the pending slots. The pending slots queue is made up of connected clients that requested an upload slot. Thus the number of clients in the queue depends on the frequency of upload slots requests, and the average timeout before connection drop.
Traditionally, MLdonkey does not try to put an upper bound to what is sent to an uploader. That behavior can now be changed with dynamic_upload_lifetime. This can be used to try and increase the likelihood of an upload of full chunks.
See also
uploaders, dynamic_slots, dynamic_upload_lifetime, incoming_directory_prio
Languages: English