Calan

"And very shortly afterwards, probably more than half the new seeds leave." Not sure what scenarios you have experienced, but the majority of torrents I download are on private trackers with sustained high seed:peer ratios, with many of the seeds being seedboxes, even one of which could max out my connection. Thus the following changes would be made to your calculation (note that the majority of these numbers are just estimated from what is required of the average private tracker user): 80 seeds + 2 peers In a worst case scenario, 90% of seeds are remaining just minutes after being last seen On average, about 5% are firewalled (if you can't seed, you can't maintain ratio, so you can't stay on the site) Maybe 5% are on hostile ISPs or have really pathetic max upload speeds (see above) Maybe 0% of the ips are duplicates of the same seed/peer (on private trackers, each user can only have 1 IP associated with their account at any given time, I believe). Each averages about 50KB/sec upload per upload slot (this is a conservatively low estimate, as the seedboxes would likely skew that number up by a large amount), and using the correct fraction since we've only got 2 peers, not 40, they only upload to a particular peer maybe 1/2 of the time. 82 total peers+seeds x 90% remaining x 100% unfirewalled x 95% not on hopelessly hostile ISPs x 100% aren't duplicated ISPs x 50KB/s upload speed x 50%= About 1.75 MB/sec upload from all that. For your calculation to hold true, the following conditions would have to apply: 1. A torrent on a public tracker. The situation you're describing, where 50+% of users hit and run, does not happen on private trackers due to DL:UL ratio requirements. 2. A torrent which has, moments ago, finished initial seeding and converted the majority of peers to seeds. This period is brief, is it not? i.e. the chances that a significant number of people will join a torrent just after it has finished initial seeding, but just before seeds drop off like flies, and then have that as the torrent they choose to have download sequentially, then manually set it to download sequentially, thus crippling the torrent... Those chances are quite remote. 3. A torrent where the only remaining seeds are peers seeding from a home connection with an upload limit set at 12KB/s (am I right in assuming that's what you meant by 4 upload slots, max 3KB/s/slot?). If there were servers as seeds, or even users with fast home connections, the torrent could survive even with sequential downloaders for the period of time between tracker polls by the SDs, who then would stop being SDs, thus removing the threat to the torrent. From this, I assume two things: 1. Sequential downloading implemented in the manner I described in my previous post would not pose a threat to private trackers, which many people use. 2. Sequential downloading implemented in the manner I described in my previous post would pose a threat to torrents on public trackers, but the threat would be very unlikely to kill a torrent in the worst case scenario, and in average or best case scenarios would pose insignificant or no threat.

Wouldn't an easy solution to this be to have this as a manual feature (i.e. you have to select it on each torrent or something), have it only be able to be used on 1 active torrent (as chances are that the only reason you would want to sequentially download is to be able to view the file while it is downloading), and have it only be able to be used when the seed:peer ratio is >#? For example, if I were on a torrent with 80 seeds and 2 peers, it is extremely unlikely that sequential downloading by either or both of the peers would result in the torrent's death. If I were on a torrent with 3 seeds and 10 peers, sequential downloading could indeed have adverse effects, and thus should not be able to be enabled. Many people download multiple torrents at a time, so limiting it to one active torrent sequentially downloading would greatly reduce the number of people downloading sequentially on any given torrent. Many people download single torrents, but in a queue, so having the feature be manual (i.e. each time a new torrent starts, the feature would have to be enabled, and further, each time the client starts the feature could have to be re-enabled on a specific torrent) would greatly reduce the number of sequential downloaders. And lastly, limiting it to torrents with a minimum seed:peer ratio would ensure that sequential downloading could only be used on torrents where it presented little or no risk to the integrity of the swarm. This would essentially cripple this feature to a point where its existence would be inconsequential to the swarm's integrity, yet still be an extremely useful feature for many users.