4 ms·
The upload speed for S3 seeding was usually between 72 and 80 KiB per second So not horribly helpful for larger blobs that you expect to have a lot of initial
by aroch 12y ago
The upload speed for S3 seeding was usually between 72 and 80 KiB per second
So not horribly helpful for larger blobs that you expect to have a lot of initial demand for. You'd be better off serving the blob or renting a seedbox / cheap server if you want to do initial seeding for distribution if you were interested in your users experience.
- toomuchtodo 12y agoThe benefit isn't in serving the data from S3. The benefit is that S3 is an indestructible tracker. If you remove public-read from an object, S3 will continue to serve as the tracker for the object for the swarm.
- aroch 12y agoThat's hardly a benefit, there are plenty of open trackers and DHT/PEX solves most problems.
- ceejayoz 12y agoNone of them will seed on your behalf, though.
- dublinben 12y agoS3 will only do so because you're paying by the MB. It's not a free service.
- ceejayoz 12y agoSure, but that's a perfectly fine tradeoff for some folks who want the torrent to stay up.
- aroch 12y agoAnd AWS isn't seeding out of the kindness of their hearts, you're paying them to.
- ceejayoz 12y agoSure, but that's a perfectly fine tradeoff for some folks who want the torrent to stay up.
- mikeash 12y agoProviding an extra seed seems useful too. You can do the initial seed from somewhere faster, but S3 will provide a backstop in case that seed goes down. It might be too slow for the full download, but it can help fill in the last little pieces in case you get into a situation where everybody in the swarm has 99% of the file but nobody has some particular chunks.
- toomuchtodo 12y agoCORRECTION: It was pointed out by /u/teraflop that the Bittorrent functionality and Requestor Pays functionality are incompatible on the same bucket. Indeed. S3 also has the ability to have the requestor pay for the bandwidth costs of a object retrieval. You could, for example, get the object free from the swarm, and pay for the last few MB/GB if it was unavailable from anyone else. http://docs.aws.amazon.com/AmazonS3/latest/dev/RequesterPaysBuckets.html http://docs.aws.amazon.com/AmazonS3/latest/dev/RequesterPays... http://docs.aws.amazon.com/AmazonDevPay/latest/DevPayDeveloperGuide/S3RequesterPays.html http://docs.aws.amazon.com/AmazonDevPay/latest/DevPayDevelop...
- teraflop 12y ago"Requester Pays buckets do not support the following. [...] BitTorrent"
- toomuchtodo 12y agoCorrected and cited. Thanks.
- mikeash 12y agoI didn't know about the requestor pays functionality, so it's good to know that even if it doesn't apply here.
- fat0wl 12y agoYah exactly -- you can seed the file yourself but just have this as a backup in case your PC/laptop/whatever is turned off. Slower, but at least its there. Once it is seeded beyond a couple initial users it's a moot point anyway. Doubt that AWS is trying super hard to get into the torrent sphere, its just +1 cool thing they support.
- oakwhiz 12y agoInstead of using the BitTorrent feature of S3, it might be more effective to check the popularity and health of your torrent, and then when it is suitable, spin up a small EC2 instance running a BitTorrent client to seed the torrent. You should be able to achieve better performance this way, and you can shut down the instance when the torrent is healthy. Alternatively, there is also the possibility of using the HTTP seeding extension to the BitTorrent protocol (BEP17/BEP19) which is supported by most clients.
- aroch 12y agoFor even a modestly sized blob with a relatively small swarm you'd get hit with tens of thousands of requests due to block requests, you'd be spending more on bw+requests than is probably worth it.