aquatic

I actually ran a very-short-lived private use tracker briefly, for some exploration doing p2p watch partying. But it was a toy, never got serious enough to look deeper at how the tracker worked (was using the rust Aquatic tracker, which kindly added webtorrent support on request! https://github.com/greatest-ape/aquatic ) Does the tracker know what it's tracking? Is there any attempt to make the tracker unaware of what peer rendezvous it's doing? My gut is that it seems some kind of hash/magnet that folks are asking to peers on. And that the magnet itself is sufficient, and doesn't have to include anything identifying (although I believe many magnet links included some human readable description). The tracker could likely try to download this hash from the peer itself, to get the torrent info, but wouldn't really know what the torrent is o

How does Bitmagnet compare to Aquatic? https://github.com/greatest-ape/aquatic

I’ve achieved great preliminary results with this in https://github.com/greatest-ape/aquatic#io_uring

If you run your tracker on Linux and an info hash whitelist approach would work for your use case, it might be worthwhile to have a look at aquatic_ws [0]. It relies on tungstenite [1] for websockets and achieves around 20x the throughput of the reference implementation when running with four threads. I don’t know of anybody who runs it in production, but its sister implementation (BitTorrent over UDP) handles 80k responses per second with lower load averages than opentorrent. [0] https://github.com/greatest-ape/aquatic [1]: https://github.com/snapview/tungstenite-rs (I am the developer of aquatic)