3 ms·
Yes but the peers with less blocks tend to catch up to the peers with slightly more blocks as they can download from more peers. This means you reach a point wh
by arg01 13y ago
Yes but the peers with less blocks tend to catch up to the peers with slightly more blocks as they can download from more peers. This means you reach a point where all the peers are after roughly the same set of blocks and few of the peers have them, so the system is limited by connections to seeders.
It effectively degrades the delivery (especially near the source) into something akin to a tree shape rather than a mesh. This can choke the network considerably. This situation would be best alleviated by guaranteeing that when a peer connects to the seeder/peer it downloads a block that is least common in the network, or failing that (the overhead would be horrible) a random block.
This is largely an issue while the torrent has few seeders (i.e. it's young but many people are trying to download it) and you'd be right in assuming that once the file has been available for a while the high demand would improve performance (in the sense there are more people to download from) it's just the initial download for those first trying to download the torrent would be slower (potentially much slower). Though seeders that drop out after completing a certain share/download ratio can cause the more rare end of file pieces to be in even shorter supply as the majority of requests they receive are for the start of file as the swarm grows.
- sp332 13y agoI think the default is for a client to request the least common block from its point of view. If it has 8 peers and only 1 of them has a block, it will get that one first. That way it can then deliver that block to any of the other 7 that it's already connected to. This gets many of the benefits without all the overhead of picking the globally-rarest block.