Seeding torrents from S3 | Hacker News Reader

Seeding torrents from S3

blog.celingest.com

61 pointscelingest25 comments

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.

    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.

That's hardly a benefit, there are plenty of open trackers and DHT/PEX solves most problems.

None of them will seed on your behalf, though.

S3 will only do so because you're paying by the MB. It's not a free service.

And AWS isn't seeding out of the kindness of their hearts, you're paying them to.

Sure, but that's a perfectly fine tradeoff for some folks who want the torrent to stay up.

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.

http://docs.aws.amazon.com/AmazonS3/latest/dev/RequesterPays...

http://docs.aws.amazon.com/AmazonDevPay/latest/DevPayDevelop...

"Requester Pays buckets do not support the following. [...] BitTorrent"

Corrected and cited. Thanks.

I didn't know about the requestor pays functionality, so it's good to know that even if it doesn't apply here.

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.

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.

Quick question: is anyone here using BT Sync with S3? I'd like to know about the experience, ease of use, access, redundancy, etc.

I might be wrong, but I don't think Bittorrent Sync uses the same data or tracker protocols, so S3 wouldn't support it.

I'm sure plenty of people use it on their EC2 instances though.

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.

https://sites.google.com/site/torrenttricks/use-dropbox-as-a...

Dropbox is going to cut you off much faster than S3 if you're attempting to serve torrents from them.

I've heard of dropbox cutting off high traffic files a couple of times, anyone have the specifics on what constitutes high traffic though?

https://www.dropbox.com/help/4204/en

"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."

So $2.50 worth of S3 outbound transfer (for personal accounts).

Reply on news.ycombinator.com