mldonkey-bugs
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Mldonkey-bugs] [bug #17827] Latest stable release ignores max_upload_sl


From: spiralvoice
Subject: [Mldonkey-bugs] [bug #17827] Latest stable release ignores max_upload_slots
Date: Tue, 07 Nov 2006 21:11:28 +0000
User-agent: Mozilla/5.0 (X11; U; Linux i686; de; rv:1.8.0.7) Gecko/20060830 Firefox/1.5.0.7 (Debian-1.5.dfsg+1.5.0.7-2)

Update of bug #17827 (project mldonkey):

                  Status:            Works For Me => Wont Fix               
             Open/Closed:                    Open => Closed                 

    _______________________________________________________

Follow-up Comment #5:

The total number of upload slots can raise to the sum of

- max_hard_upload_slots
- BT-max_bt_uploaders
- sum of shared_directory priorities

This is caused by the design of MLDonkey.

MLDonkey does not have a queue like eMule. eMules give
clients a higher priority, so they climb faster to the
top of its queue, thats the way eMule handles sharing
specific settings.

MLDonkey can only choose from currently connected
clients when giving away an upload slot. For EDK those
clients are visible as pending slots, in BT they are
not visible and I do not know how to display them.

If max_upload_slots is observed all the time there could
be situations where for example the prio of shared dir
"share_release" is 2, but only 1 client is uploading
such a file from this dir and
real upload slots = max_upload_slots.

Now another client in pending slots asks for a file from
this dir but would not get a slot although one prio
slot is still left. So you are right about naming them
"additional upload slots", but the terminology "priority"
is used for years now.

So yes, especially when using BT, BT-max_bt_uploaders
slots are given away additionally to EDK clients.
Because BT clients seem not to download very long there
is lots of coming-and-going in the upload slots.

When real upload slots > max_upload_slots and all prios
are fulfilled a normal upload slot is not assigned until
the number of real upload slots has sunk to max_upload_slots.
This sinking does not take place often because of the fast
switching of BT clients so your observation is right.

As this is not a real bug, but intended behaviour because
of MLDonkey design choices, I am going to close this bug.

    _______________________________________________________

Reply to this item at:

  <http://savannah.nongnu.org/bugs/?17827>

_______________________________________________
  Nachricht geschickt von/durch Savannah
  http://savannah.nongnu.org/





reply via email to

[Prev in Thread] Current Thread [Next in Thread]