High-performance open BitTorrent tracker, consisting of sub-implementations for different protocols:
| Name | Protocol | OS requirements | |--------------|-----------------------------------|--------------------------------------| | aquaticudp | [BitTorrent over UDP] | Unix-like / Linux 6.0+ with iouring | | aquatichttp | [BitTorrent over HTTP] over TLS | Linux 5.8+ | | aquaticws | [WebTorrent], optionally over TLS | Linux 5.8+ |
Features at a glance:
Known users:
udp://explodie.org:6969), typically serving ~80,000 requests per secondapt-get install cmake)```sh
. ./scripts/env-native-cpu-without-avx-512
cargo build --release -p aquaticudp cargo build --release -p aquatichttp cargo build --release -p aquatic_ws ```
Generate configuration files. They come with comments and differ between protocols.
sh
./target/release/aquatic_udp -p > "aquatic-udp-config.toml"
./target/release/aquatic_http -p > "aquatic-http-config.toml"
./target/release/aquatic_ws -p > "aquatic-ws-config.toml"
Make adjustments to the files. You will likely want to adjust address
(listening address) under the network section.
Note that both aquatic_http and aquatic_ws require configuring certificate
and private key files to run over TLS. aquatic_http only runs over TLS.
More details are available in the respective configuration files.
To increase performance, number of worker threads can be increased. Recommended proportions based on number of physical CPU cores:
| udp | http | ws | ||
|---|---|---|---|---|
| CPU cores (N) | N | N | 1-7 | >=8 |
| Swarm workers | 1 | 1 | 1 | 2 |
| Socket workers | N | N | N | N-2 |
Access control by info hash is supported for all protocols. The relevant part of configuration is:
```toml [access_list]
mode = "off"
path = "" ```
The file is read on start and when the program receives SIGUSR1. If initial
parsing fails, the program exits. Later failures result in in emitting of
an error-level log message, while successful updates of the access list result
in emitting of an info-level log message.
Exporting Prometheus metrics is supported. Activate the endpoint in the configuration file:
toml
[statistics]
run_prometheus_endpoint = true
prometheus_endpoint_address = "0.0.0.0:9000"
toml
[metrics]
run_prometheus_endpoint = true
prometheus_endpoint_address = "0.0.0.0:9000"
If you're running aquatic_http or aquatic_ws, please make sure locked memory
limits are sufficient:
- If you're using a systemd service file, add LimitMEMLOCK=65536000 to it
- Otherwise, add the following lines to
/etc/security/limits.conf, and then log out and back in:
* hard memlock 65536
* soft memlock 65536
Once done, start the application:
sh
./target/release/aquatic_udp -c "aquatic-udp-config.toml"
./target/release/aquatic_http -c "aquatic-http-config.toml"
./target/release/aquatic_ws -c "aquatic-ws-config.toml"
If your server is pointed to by domain example.com and you configured the
tracker to run on port 3000, people can now use it by adding its URL to their
torrent files or magnet links:
| Implementation | Announce URL |
|----------------|-------------------------------------|
| aquaticudp | udp://example.com:3000 |
| aquatichttp | https://example.com:3000/announce |
| aquatic_ws | wss://example.com:3000 |
Implements: * [BEP 015]: UDP BitTorrent tracker protocol (more details). Exceptions: * Doesn't care about IP addresses sent in announce requests. The packet source IP is always used. * Doesn't track the number of torrent downloads (0 is always sent).
This is the most mature of the implementations. I consider it ready for production use.
An experimental io_uring backend is available. It currently requires Linux
6.0 or later and will attempt to fall back to the [mio] backend if run with
older kernels. To enable it, pass the io-uring feature when compiling:
sh
cargo build --release -p aquatic_udp --features "io-uring"
The mio backend was used. More details are available here.
Implements: * [BEP 003]: HTTP BitTorrent protocol (more details). Exceptions: * Only runs over TLS * Doesn't track the number of torrent downloads (0 is always sent) * Only compact responses are supported * [BEP 023]: Compact HTTP responses * [BEP 007]: IPv6 support * [BEP 048]: HTTP scrape support. Notes: * Doesn't allow full scrapes, i.e. of all registered info hashes
aquatic_http has not been tested as much as aquatic_udp but likely works
fine in production.
Running behind a reverse proxy is currently not supported due to the difficulties of determining the originating IP address without knowing the exact setup.
More details are available here.
Aims for compatibility with WebTorrent clients. Notes:
aquatic_ws has not been tested as much as aquatic_udp but likely works
fine in production.
Running behind a reverse proxy is supported, as long as IPv4 requests are proxied to IPv4 requests, and IPv6 requests to IPv6 requests.
More details are available here.
There are load test binaries for all protocols. They use a CLI structure similar to the trackers and support generation and loading of configuration files.
To run, first start the tracker that you want to test. Then run the corresponding load test binary:
sh
./scripts/run-load-test-udp.sh
./scripts/run-load-test-http.sh
./scripts/run-load-test-ws.sh
To fairly compare HTTP performance to opentracker, set keep_alive to false in
aquatic_http settings.
Copyright (c) 2020-2023 Joakim Frostegård
Distributed under Apache 2.0 license (details in LICENSE file.)
The tracker is called aquatic because it thrives under a torrent of bits ;-)