corwin78

That is correct, technically. But I expect that a torrent availability above 1.0 would seldom be present for a large, unseeded torrent. Given the giant number of pieces in some files, it is improbable that every piece would be available. The probability of the whole thing being available looks something like this: P(A)*P(*P©*P(D)*P(E)*P(F)*... where P(A) is the probability that piece A is available. It is a product of very, very many numbers between 0 and 1 which becomes smaller as the number of pieces increases. Of course, a person can use three ip addresses, hosting a different third of the torrent with each address. Then the torrent can have zero seeds, and a forced availability of 1.0. But for this discussion, I consider that example to be a method of seeding by using a workaround. The high odds that a whole torrent wouldn't be available without seeds illustrates the importance of developing seeds which preferentially distribute pieces which are scarce among peers. Seeds should not be told which pieces to distribute. Seeds should act as if unfinished peers are willing to take any of its missing pieces. That way, a seed's role in keeping the torrent alive is unlikely to be wasted by sequential downloaders. It may also be a good idea to establish a certain minimum number of pieces into which a very large torrent would be divided.

I'm still not sure that sequential downloading kills torrents. But disappearance of seeds certainly does. I recognize the problem of stratification, which is an inability of peers to trade. Stratification is a condition like this: Peer A has some fraction of the torrent, and has all of the pieces available on the network at the moment. Peer B has some fraction of A's pieces, and nothing more. Peer C has some fraction of B's pieces, and nothing more. Peer D has some fraction of C's pieces, and nothing more. Every peer has a different amount of the torrent, and none of the peers are capable of swapping pieces. Stratification would eventually happen in an environment where there is no seed, and every peer insists on getting pieces quickly in exchange for its bandwidth. If the torrent had sequential downloaders, the lower strata would tend only to have the beginning of the file. The higher strata would tend to be missing only the end of the file. If you see a stratified dead torrent with evidence of sequential downloading, it is easy to blame sequential downloading for the death of the torrent. But the torrent actually died from stratification. If the torrent does not have sequential downloaders, stratification can still happen. The only difference is that the downloaded pieces will look more scattered on each peer's map of the file. If a seed returns to the network, all of the stratified peers will be newly motivated to send pieces downstream because seeds reward peers for providing bandwidth. A torrent should not become stratified as long as seeds are uploading. It seems as if torrents need seeds, period. Peers that share while downloading will reduce the bandwidth burden on the seeds. But the torrent concept does not work unless seeds remain available. Well-designed seeds will distribute pieces to peers that are good at sharing. They will preferentially distribute rare pieces on the network. They will try to send the pieces to low strata, because this increases the number of times that the pieces will be copied as they "bubble up" to the higher strata through swapping.

Thank you. The behavior looks clearer to me now. Speaking of hit-and-run downloaders, sequential downloading may cause them to be worse sharers than they already are in a random upload/download environment. The last pieces that they receive may be least likely to get uploaded by them before they leave. Do you think that sequential downloading by other peers is the reason why my download was extremely "end heavy", or do you think it is a coincidence? The last dead torrent in which I participated seemed to be "dead all over", not dead at the end. But I don't have much experience with Bittorrent to know how torrents usually die. The "bt.prio_first_last_piece" option seems silly. There is usually no motive to prioritize the end pieces, and the option implies sequential downloading on both ends. It seems better to mix sequential downloading the beginning with preferentially requesting rare pieces.

I know this is an old debate, but I'm unconvinced that sequential downloading harms torrents. In an environment where every peer downloads pieces sequentially without exception, the rarest pieces will be at the end of the torrent. In that case, the end of a torrent is at risk of falling out of the network altogether. But in reality, I see a self-correcting situation. While downloading a file, I noticed on my graphic indicator that my download was "end heavy". The further a piece was from the beginning of the file, the more likely I was to have received it. In a mixed environment of sequential downloaders (SDs) and non-sequential downloaders (NSDs), wouldn't the activity of the SDs cause the NSDs to preferentially trade end pieces, thus balancing piece availability on the network? I am presuming that the NSDs prefer to download rarest pieces first, and that they know what pieces are rare by polling the swarm (or asking the tracker, as the case may be). Whatever pieces the SDs make rare, the NSDs will want to trade. Sequential downloading is preferred by users who want to preview the files to decide whether they want to finish downloading them. If a sequential option is built into a Bittorrent client, it may be wise to design it so that the client alternates between requesting sequential pieces and rare pieces. It could boost piece availability and give "file insurance" to the individual user against losing the ability to download rare pieces toward the end.