News for hackers. Stuff that matters.
Re:BitTorrent vs. HTTP by kiliankoe on Tuesday January 24, 2017 @07:00AM (#13470656)
> While clients (probably) could ask for chunks in a chronological order and then get the data in a sequential manner [...]

Why probably? This is exactly how the immensely popular Popcorn Time worked.

Re:BitTorrent vs. HTTP by fnord123 on Tuesday January 24, 2017 @07:18AM (#13470721)
It's literally in the same sentence. In the part that you elided:

"it will not at all distribute the load as evenly among the peers as the "random access" method does."

If people only stay to download the file and then disconnect then there will be a higher concentration of parts from the beginning of the file than to the end. This reduces the resiliency of the swarm.

Re:BitTorrent vs. HTTP by kiliankoe on Tuesday January 24, 2017 @07:32AM (#13470786)
I only wanted to bring up that the beginning of the sentence made it sound like a theoretical concept that might work, but no one has ever tried or seen in practice. The concerns are definitely valid.
Re:BitTorrent vs. HTTP by Retric on Tuesday January 24, 2017 @07:48AM (#13470876)
Depends on the algorithm but you need not go 100% one way or the other. The basic rule can be 70% download next part and 30% download rare bits. The swarm is slightly less resilient, but seeders are still generally uploading the rare bits not the start of the file. This also tends to make a faster swarm as new downloads have something to trade.
Re:BitTorrent vs. HTTP by WhiteOwlLion on Tuesday January 24, 2017 @01:49PM (#13474262)
You could have an algorithm change how pieces are requested based on availability (seed to peer ratio). If a torrent has high availability, then there is little harm in retrieving pieces sequentially.
Re:BitTorrent vs. HTTP by wjh_ on Wednesday January 25, 2017 @03:18AM (#13479686)
While I admit that this is less than ideal, it's not quite as bad as it may seem.

For instance, if it's a movie being streamed, the majority of connections will finish downloading the movie long before the user finishes watching, making a pretty decent seed time. Those with a slower connection wouldn't have made a particularly great seed anyway.

Re:BitTorrent vs. HTTP by dest on Tuesday January 24, 2017 @07:33AM (#13470792)
Side note: AFAIK Popcorn time generally uses very crowded swarms (e.g. YIFY torrents) so chronological downloads do not kill the swarms.
Re:BitTorrent vs. HTTP by shawabawa3 on Tuesday January 24, 2017 @07:37AM (#13470821)
chronological downloads never really kill swarms. If everyone is downloading chronologically, then the earlier pieces are more in demand, but they also have more supply

The only thing that kills swarms is average seed ratio < 1

Re:BitTorrent vs. HTTP by numerlo on Tuesday January 24, 2017 @08:03AM (#13470961)
They do as the supply of the final pieces is low and if they go offline the torrent could die. Happens a lot in less popular torrents.
Re:BitTorrent vs. HTTP by geoah on Tuesday January 24, 2017 @07:09AM (#13470692)
The non-random fetching is also how super-seeding works [1].

https://en.wikipedia.org/wiki/Super-seeding

Re:BitTorrent vs. HTTP by anonymfus on Tuesday January 24, 2017 @07:09AM (#13470691)
Most clients support this in some way. In qBittorrent it's a context menu option, for example.
Re:BitTorrent vs. HTTP by masklinn on Tuesday January 24, 2017 @08:56AM (#13471280)
Likewise Tixati, on a per-file basis you can ask for a sequential download (prioritise downloading the file in sequential order) and "head and tail" (further prioritise the first and last 500k, as some file formats require a header and a footer to start using).