Re: [Mldonkey-users] [pango 20030105a] new chunks order

[Lionel Bouton]

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...