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.
The 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.
Providing 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.
CORRECTION: 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.
Yah 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.
Instead 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.
For 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.
Why?
This would work... until the surprise bandwidth bill comes in.You could just do this for free using dropbox though, or another less expensive object storage.
"For Basic accounts, the total amount of traffic that all of your links together can generate without getting banned is 20 GB per day. For Pro and Business accounts, the limit is 200 GB per day."
This is probably an incredibly expensive way to seed torrents. There are any number of seedbox providers who will give you several hundred GB of storage, several TB of traffic, and much higher speeds for a flat rate of ~$15 a month.
Another idea: you could also use S3 as a web seed for a .torrent you hosted somewhere (or even a magnet link); it seems likely the speeds would be much better as well, since you'd be able to take advantage of S3's load-balancing.
+1 for web seeds. You can also avoid having a tracker at all if you use PEX and DHT-only magnet links.
Tangent: I ran into a strange bug with web seeds using Transmission on Debian Wheezy the other day: it does not respect the configured speed limit for web seed sources, owing to a discrepancy in the way libcurl vs libtransmission downloads are handled. It's fixed now but not in Wheezy.
26 comments
[ 4.9 ms ] story [ 44.6 ms ] threadIndeed. 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/RequesterPays...
http://docs.aws.amazon.com/AmazonDevPay/latest/DevPayDevelop...
Doubt that AWS is trying super hard to get into the torrent sphere, its just +1 cool thing they support.
Alternatively, there is also the possibility of using the HTTP seeding extension to the BitTorrent protocol (BEP17/BEP19) which is supported by most clients.
https://sites.google.com/site/torrenttricks/use-dropbox-as-a...
"For Basic accounts, the total amount of traffic that all of your links together can generate without getting banned is 20 GB per day. For Pro and Business accounts, the limit is 200 GB per day."
I'm sure plenty of people use it on their EC2 instances though.
Tangent: I ran into a strange bug with web seeds using Transmission on Debian Wheezy the other day: it does not respect the configured speed limit for web seed sources, owing to a discrepancy in the way libcurl vs libtransmission downloads are handled. It's fixed now but not in Wheezy.