patchmldonkey, a multi-networks file-sharing client - Patches: patch #3655, Bugfix for multiple...

 
 

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

patch #3655: Bugfix for multiple sourceexchanges with the same peer (2.5.28)

Submitter:  Fritz Mock <surround>
Submitted:  Mon 17 Jan 2005 11:54:36 PM UTC
   
 
Category:  Bug fixes Priority:  9 - Immediate
Status:  Done Assigned to:  None
Open/Closed:  Closed

Sun 20 Feb 2005 02:54:49 AM UTC, comment #4: 

applied 2-5-28-1

spiralvoice <spiralvoice>
Group administrator
Wed 19 Jan 2005 10:41:41 AM UTC, comment #3: 

No I did not look at the upload queue yet, since upload is ok for me.

DSL 128KBit/s upstream, propagate_sources false <- very important!, max_hard_upload_rate 0, max_upload_slots 3, 3 prio slots from shares => 10-11 KB/s upload, depends on the downloads-set, with many very wiedespread files upload can go down do 7 KB/s. The reason for that is the traffic caused by sourceexchange. Working on the next patch to solve some issues with sourceexchange's bandwith demand.


Fritz Mock <surround>
Tue 18 Jan 2005 07:07:46 PM UTC, comment #2: 

great fix! did you look at mldonkey upload queue too?

devein
Tue 18 Jan 2005 12:35:55 AM UTC, comment #1: 


oops, before someone asks, the patch is for donkeyClient.ml ;)


Fritz Mock <surround>
Mon 17 Jan 2005 11:54:36 PM UTC, original submission:  


Sourceexchange is pretty screwed in mldonkey 2.5.28 (and probably is in a couple of versions earlier, too.)

After receiving a QueryFileReq mlDonkey will (amongst other things) send an EmuleRequestSources Request, if it also downloads that file. i.e. if another peer asks us for a file we are downloading, we are asking the other peer to send us sources for that file.
Additionally it will register that cient in source and only a little bit later, mldonkey will send a QueryFileReq himself. (We try to initiate a download from the other peer, too.)

Of course, the other peer wil reply on that request, confirming that it is in possesion (at least partially and having nothing downloaded yet is also possessing partially) of that file.
After receiving a QueryFileReplyReq our mlDonkey checks if the other peer is a mldonkey2 or mldonkey3 and if that is the case it sends a SourceReq (list containing IP's of known clients that share that file.)
After that it additionally sends an EmuleRequestSourcesReq to if the other peer is able to do sourceexchange, i.e. mldonkey requests sources from the other peer, if it confirms the possession of a file. (That in itself is a mistake, because a client confirming that it has the file in question does not confirm, that it manages source for it. A peer with a complete file cannot send sources to us!)

Therfore in the worst case scenario, mldonkey <-> mldonkey (both with propagate_sources true) we receive the sources for one download 3 times in a row and send our source 3 times in a row, too!
With other clients than mldonkey it is a little better, we only do 2 sourceexchanges.

Besides the unneccessarily wasted bandwidth, there is some more ...

- Many emule clients will simply reset connection when they receive the secondexchange request.
- A shareaza client will, if it also receives a uploadslot on our donkey not be able to cope with the situation. It will be paralyzed and allocate the uploadslot not transfering any data, until after 20 minutes mldonkey kicks that client.

Patch against 2.5.28n to solve that issue is attached. It also adds some more information to the logging output.

Fritz Mock <surround>

 

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

Attached Files
file #8275:  3655_2.patch added by spiralvoice (10KiB - application/octet-stream - the same patch as unified diff)
file #8273:  multsrcxchgfix added by surround (6KiB - application/octet-stream)

 

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 4 latest changes.

Date Changed by Updated Field Previous Value => Replaced by
2005-02-20 spiralvoice Open/ClosedOpen Closed
2005-01-28 amorphous StatusNone Done
2005-01-18 spiralvoice Attached File- Added 3655_2.patch, #4058
2005-01-17 surround Attached File- Added multsrcxchgfix, #4056

Back to the top

Powered by Savane 3.13-02a9.
Corresponding source code