bugmldonkey, a multi-networks file-sharing client - Bugs: bug #17827, Latest stable release ignores...

 
 

You are not allowed to post comments on this tracker with your current authentication level.

bug #17827: Latest stable release ignores max_upload_slots

Submitter:  Rolf Leggewie <leggewie>
Submitted:  Sat 23 Sep 2006 11:14:11 AM UTC
   
 
Category:  Core Severity:  3 - Normal
Item Group:  Program malfunction Status:  Wont Fix
Assigned to:  None Open/Closed:  Closed
Release:  2.8.1 Release:  2.8.1
Operating System:  Linux Binaries Origin:  Binary from Savannah
CPU type:  Intel x86

Tue 07 Nov 2006 09:11:27 PM UTC, 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.

spiralvoice <spiralvoice>
Group administrator
Tue 07 Nov 2006 07:42:46 PM UTC, comment #4: 

yes, I believe I do.  Although I cannot pinpoint it.  It seems to occur more often when I have Bittorrent running.  But maybe I just misunderstand the whole concept of max_upload_slots which I have set to 4.  Sometimes, I get up to seven downloaders.

Can you change "priority" to "additional upload slots"?

All in all, not a big deal.

Rolf Leggewie <leggewie>
Tue 07 Nov 2006 06:42:30 PM UTC, comment #3: 

Do you still see this bug?

spiralvoice <spiralvoice>
Group administrator
Fri 06 Oct 2006 04:03:14 PM UTC, comment #2: 

Ping

spiralvoice <spiralvoice>
Group administrator
Sat 23 Sep 2006 02:10:05 PM UTC, comment #1: 

OK, this might be related to a very unintuitive wording of "priority" when what is really meant is "additional upload slots"

I found this out via http://temp.mldonkey.org/forum/viewtopic.php?t=4296 but I am not sure it does work as it should even ignoring the awkward wording (I do consider this wording to be a bug in itself).

I will continue to monitor this and report back on how this works out.  Please do not close the bug.

Rolf Leggewie <leggewie>
Sat 23 Sep 2006 11:14:11 AM UTC, original submission:  

Hi,

I have set the maximum number of upload slots to 5.  About an hour after restarting mlnet, there were nine upload slots filled (do not know if that was the case from the start).  I disconnected from a couple of clients with Sancho GUI but the slots were reallocated.

I run bittorrent and edonkey.  A maximum of three slots are reserved for bittorrent.  And usually that rule is observed.

Regards

Rolf

Rolf Leggewie <leggewie>

 

(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

No files currently attached

 

Depends on the following items: None found

Items that depend on this one: None found

 

CC list is empty

 

There are 0 votes so far. Votes easily highlight which items people would like to see resolved in priority, independently of the priority of the item set by tracker managers.

 

Follow 3 latest changes.

Date Changed by Updated Field Previous Value => Replaced by
2006-11-07 spiralvoice StatusWorks For Me Wont Fix
    Open/ClosedOpen Closed
2006-09-25 spiralvoice StatusNone Works For Me

Back to the top

Powered by Savane 3.12