Re:After 15 Years, the Pirate Bay Still Can’t Be Killed
by reacweb on Friday May 24, 2019 @03:58AM
(#19999419)
You are assuming all the peers start at the same time. It would be more fair to assume that the peers start regularly. In this case, the order does not cause issue.
Re:After 15 Years, the Pirate Bay Still Can’t Be Killed
by afiori on Friday May 24, 2019 @05:23AM
(#19999836)
But then you are assuming that people will seed for an considerable time (more that a few minutes) after watching the stream. If as many people do they do not seed then the last block will forever only have one seeder. (which would at least be the case for the last scene of the last episode of the last season, a point where you might not like buffering)
Re:After 15 Years, the Pirate Bay Still Can’t Be Killed
by anoncake on Friday May 24, 2019 @07:22AM
(#20000354)
If you make that the default, almost all people will continue to seed unless they never use the software again.
Re:After 15 Years, the Pirate Bay Still Can’t Be Killed
by afiori on Friday May 24, 2019 @11:04AM
(#20002258)
There is a fundamental assumption underlying this topic, are the user expected to be on desktop or mobile (including many laptops)? If the objective is to provide high bandwidth then mobile users might see a significant increase in battery and disk usage.
not saying it would not work, I actually like the idea of more peer to peer networking. But as the market is clearly focused on low consumption user devices with commonly little drive capacity seeding would be a damage to UX.
Re:After 15 Years, the Pirate Bay Still Can’t Be Killed
by anoncake on Friday May 24, 2019 @03:30PM
(#20004618)
Phones at least have smaller screens and need lower resolutions. But that doesn't really solve the problem.
You're the seeder. Initially you're the only one with all 100. And everybody's gonna download things sequentially.
Imagine 300 peers grab block 1 from you. Gonna be pretty slow, each peer gets 1/300th of your bandwidth.
Imagine those 300 peers finish block 1 and move onto block 2. Same bandwidth crunch. Although new peers can at least get block 1 from that initial cohort of 300 peers. But nobody can blocks 2 through 100 from anybody but you. Not ideal.
Now repeat the process for 3 through 100. You're gonna be the bottleneck for a loooooooong time for those remaining pieces.
...
...
...now imagine we do it differently. Those 300 peers each grab a random block. This part's just as slow.
But once they have their initial randomly-chosen blocks, our bandwidth explodes. Each of those 100 blocks is now available from ~4 sources (you, and roughly 3 others). And you could even log off at this point, since there is a complete (distributed) copy of your file out there.
As more blocks are exchanged, the effective aggregate bandwidth rapidly increases even farther.