|
From: | Lionel Bouton |
Subject: | Re: [Mldonkey-users] [pango 20030105a] new chunks order |
Date: | Wed, 08 Jan 2003 02:06:30 +0100 |
User-agent: | Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.3a) Gecko/20021212 |
Goswin Brederlow wrote:
This is why in my opinion to maximize the spreading speed you'd better control the uploads : When you start spreading a file, you don't want to send the same chunk to several peers :Afaik does mldonkey already do that. If its uploading a chunk it hides that chunk from other clients. It apears like he doesn't have it and thus they won't download it.
This is good. What I proposed went a little further but was based on assumptions that you proved me wrong. Everything is now flat on the floor :-(
To sum up and make sure I've understood :When you enter a queue you don't tell what you want -> the potential uploader can't manage a priority in the queue on this basis. Peers don't publish chunk availability and the protocol isn't chunk download oriented (eDonkey uses a plain byte-range).
What I believed was possible is some sort of "pipeline" publishing : first publisher pushes the chunks in whatever order to others but can make sure the whole file is uploaded before a chunk is rescheduled for an upload. During this first push, peers having downloaded complete chunks start to publish them, doubling their availability on the network. If they would have done the same (only uploading a chunk if others weren't uploaded less), the second stage of the pipe would also have maximised the spreading capability of the network and so on.
This is maybe more like what bittorent does effectively using a completely different protocol.
The above can't happen efficiently with eDonkey, the files are published by everyone with a valid chunk but peers spend their time jumping from peers to peers looking for chunks they don't have (peers don't publish data they haven't validated by MD4 do they ?).
LB, maybe dreaming a little too much...
[Prev in Thread] | Current Thread | [Next in Thread] |