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

[Goswin Brederlow]

Lionel Bouton <address@hidden> writes:

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

Thats what I hope. Never actually looked into the specific network
packet that gets send there. maybe I should.
 
> Peers don't publish chunk availability and the protocol isn't chunk
> download oriented (eDonkey uses a plain byte-range).

They do publish chunk availability and checksumms for each chunk.
But there must be some way to say I already have xxx bytes of a chunk
just gimme the remaining part. You don't redownload all 9 MB just
because your missing 1 Byte at the end.

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

Yes. One should certainly do that with new files. But normaly you
reshare files and then it would be better to push chunks that are rare
(because the people who got that chunk first went offline or some
other reason).
 
> 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

The publish that they have the file (or chunks of it) at the servers
and what chunks they have between clients.

Otherwise the servers would have to remember far too much information.

> don't publish data they haven't validated by MD4 do they ?).

I sure hope not but some seems to do it anyway. Otherwise getting more
than 100% of a file doesn't realy make that much sense. A crc32 is
quite save for transferes and far to often you have to download >100%.

> 
> 
> LB, maybe dreaming a little too much...

MfG
        Goswin