3 ms·
Sorry for the stupid question, but how was this used previously? You could just set all your torrents to download to Amazon's cloud?
by DaftDank 5y ago
Sorry for the stupid question, but how was this used previously? You could just set all your torrents to download to Amazon's cloud?
- jes5199 5y agothe other way - S3 could seed directly to a torrent, I think
- takeda 5y agoFor example Linux distro could provide a DVD image. When your users would chose to use torrent you could get huge savings in bandwidth if file is popular, also the users would enjoy higher throughput.
- staticassertion 5y agoI'm not knowledgeable on bittorrent but I feel like it should still be 'compatible' (with a shim layer) with S3, just maybe not natively.
- KingMachiavelli 5y agoYou should still be able to effectively use S3 via Webseeds - the Bittorrent protocol specifies including http sources in your torrent file. The only big issue is that not all torrent clients support it.
- Sunspark 5y agoIf doing this stops someone from their precious, they will update their clients right away.
- banana_giraffe 5y agoI don't know of the internals, but on the surface there were three things this did: A torrent creator. This is a simple extension to the REST endpoint of S3, and a specific S3 API, that'd scan a S3 object to create the torrent file, and register the resulting infohash with a tracker. A tracker. Technically not necessary, but with the implementation AWS went with, they needed to run their own tracker to allow peers to discover each other. A seed peer. This was probably a shim on S3 (if I recall correctly, the IP was within the S3 range of IPs). This was responsible for speaking BitTorrent and always having the objects available for clients to download. There are other ways to do this, but I'm sure this pile of tech was a source of abuse and problems for basically no one to use, so I'm not surprised to see it go. I also seem to recall there was a single tracker, and AWS really wants to get rid of single entry points to S3.