Seeding torrents from S3(blog.celingest.com)

61 pointsby celingest12 anni fa25 comments

blog.celingest.com

http://blog.celingest.com/en/2014/03/20/seeding-torrents-s3/?media=HNrgr6may

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

aroch12 anni fa

    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.

toomuchtodo12 anni fa

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.

aroch12 anni fa

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

ceejayoz12 anni fa

None of them will seed on your behalf, though.

aroch12 anni fa

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

ceejayoz12 anni fa

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

dublinben12 anni fa

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

ceejayoz12 anni fa

mikeash12 anni fa

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.

toomuchtodo12 anni fa

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

teraflop12 anni fa

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

toomuchtodo12 anni fa

Corrected and cited. Thanks.

mikeash12 anni fa

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

fat0wl12 anni fa

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.

oakwhiz12 anni fa

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.

aroch12 anni fa

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.

profquail12 anni fa

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.

mappu12 anni fa

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

antr12 anni fa

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

scott_karana12 anni fa

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.

teepo12 anni fa

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

toomuchtodo12 anni fa

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

Robadob12 anni fa

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

pdaddyo12 anni fa

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

toomuchtodo12 anni fa

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