young Fedora torrents spread data too slowly

Callum Lerwick seg at haxxed.com
Fri Oct 17 00:13:00 UTC 2008


On Sat, 2008-10-11 at 22:59 +0200, Denis Leroy wrote:
> As someone else mentioned, the distribution of the chunks pushed to the 
> clients is supposed to be randomized. Apparently it isn't, we're all 
> sitting here with the same completion percentage and the exact same 
> chunks, all trying to download from the same one seed.

This has nothing to do with ordering and everything to do with
bandwidth. This situation looks to me like a textbook case of a
bottleneck or throttling between the seed and that entire group of
peers. Having the same set of blocks indicates that set of peers are
well connected to each other. Or at least, better connected to each
other than to the seed. :P

> I'm not sure whether it's the client that picks the random chunk to 
> download, or the server that imposes it though. Maybe we're all using 
> the same buggy client :-) (I'm using transmission).

Well, its a P2P app. There's no server or client. When peers connect,
each peer informs the other peer of what blocks it has. A peer then
requests a block from the list of what's available. The requesting peer
will generally favor the "rarest" block from it's point of view as its
primary criteria, falling back on random selection as a secondary
criteria. The sending peer will then send the block... at its
discretion. The sending peer is also trying to maximize block
distribution, it may queue the block in favor of other peers requesting
rarer blocks. Sending peers also usually favor sending blocks to peers
who are sending them the most blocks in return. This rewards uploading
and discourages leeching.

... So there's quite a bit of handshaking both ways. The requesting
("client") peer picks what block it wants, but the sender can refuse to
send it. A peer can also "lie" about what blocks it has, forcing other
peers to pick from a subset of blocks. See: Superseeding.

http://en.wikipedia.org/wiki/Super-seeding
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 197 bytes
Desc: This is a digitally signed message part
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20081016/2005d92f/attachment.sig>


More information about the fedora-devel-list mailing list