3 ms·

There is nothing to stop a request for a specific block of the data (i.e. one close to the start). It does mean that the network is not as efficient in the case

by arg01 13y ago

There is nothing to stop a request for a specific block of the data (i.e. one close to the start). It does mean that the network is not as efficient in the case of high demand (As your more likely to have the same chunks as others and rely more on seeder). I'd assume the client (depending on how conscientious it is) just prioritizes filling a buffer and then downloads other parts of the file with any excess bandwidth.

DerpDerpDerp 13y ago
But in high demand, the start is copied many times by peers, who can reupload the start of the movie to each other.
- deleted 13y ago
  [deleted]
- 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 ago
    I 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.

by arg01 13y ago

DerpDerpDerp 13y ago

But in high demand, the start is copied many times by peers, who can reupload the start of the movie to each other.

deleted 13y ago
[deleted]
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 ago
  I 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.