An experimental server-less BitTorrent tracker with no permanent web server and no permanent database server.
See an example here! (Note that this example should be considered unstable, as I might make changes and wipe the DB from time to time for dev reasons. If you'd like to use this tracker for a real torrent, let me know so I can set up dev and production services.)
Powered by Zappa, with Amazon DynamoDB or S3 as a datastore.
Clone, virtualenv, requirements.txt. You know the drill.
Next, create a DynamoDB table.
Then open up track.py and edit your configuration. You can set DATASTORE to either S3 or DynamoDB, depending on which backend you want to use.
Run locally with run.sh, and test local announces with announce.sh.
Finally, to deploy, zappa init, zappa deploy, (optionally) zappa certify.
And you're done! You now a have a completely server-less, no-ops, low-cost, infinately scalable BitTorrent tracker!
To make sure that peers who don't gracefully close their connections are purged, add this to your zappa_settings.json:
{
"production": {
...
"events": [{
"function": "track.purge_expired_peers",
"expression": "rate(30 minutes)"
}],
...
}
}And then zappa schedule to schedule the purge as a recurring function.
With the training wheels taken off your AWS account, you should be able to handle 5,000 simultaneous connections per second, so with a 30-minute announce interval, this set-up should be able to handle 9,000,000 peers out of the box. With a multi-region deployment and a larger announce window, this should be able to scale to 100,000,000+ peers without much difficulty.
DynamoDB is the most expensive component of this. S3 should be far, far, far cheaper to use, but may have race problems in the peer tracking for high-traffic torrents.
DynamoDB is non-Free software. With Riak, OpenWhisk and Nginx (or the upcoming OpenWhisk API Gateway product), it should be possible to run this as part of an entirely Free Software server-less stack.
Rich Jones 2016. MIT License.