rlibtorrent

Measured inside rbittorrent

Four clients race for one 1 GiB private torrent: rbittorrent, qBittorrent, Deluge and rTorrent, added in the same second and fed by the same 2 seeders. A local tracker refuses the torrent until a set tracker lag has passed, as a private tracker does with a brand-new upload. Each run records when each client was first answered by the tracker, when it finished, and how much it uploaded to the others. 25 runs over four setups, every finished copy checked byte for byte. How every number was taken.

Runs rbittorrent won against the best of the other three clients in that run. A tie is not a win, and a client that never registered or finished loses that mark.

What these numbers do not cover

• One machine: 12th Gen Intel(R) Core(TM) i7-12700K, 16 GB, Microsoft Windows 10 Pro. Another machine, disk or network can order the clients differently.
• One torrent size in the race (1 GiB), and seeders on the same machine rather than a public swarm over the internet.
• Transmission and uTorrent are not in the race.
• rTorrent's CPU time and memory are not measured: it runs inside WSL, where the sampler cannot see it.

Where one add spends its time

From the moment rbittorrent accepts an add to the moment the Web UI can show it: 5.5 ms, of which the engine's own steps are 1.93 ms. Median moments over 5 runs of the first SSD session.

• waits for the add queue: 1.1 ms
• checks the request and the disk room: 0.94 ms
• the engine adds the torrent: 1.89 ms
• the product writes its records: 0.59 ms
• hands the first announce to the engine: 0.04 ms
• publishes the new torrent to the UI: 0.94 ms

What is in it

26 crates, one front door. The README's own map:

Embedding it

The daemon crate runs the whole engine in your process and hands back its addresses; this is examples/embed-daemon with its comments left out:

use rlibtorrent_daemon::{ControlListen, Listen, Mechanisms, WebListen, start};

let started = start(
    Listen::default(),
    &checkpoints,
    ControlListen::default(),
    WebListen::default(),
    None,
    Mechanisms::default(),
)
.await?;
println!("engine embedded in-process:");
println!("  peer-wire listener: {}", started.local_addr());
println!("  control surface:    {}", started.control_addr());

let report = started.stop().await?;

3 examples, each run with cargo run from its folder:

• examples/embed-daemon: Embeds the engine directly, the way rlibtorrent-daemon's own binary doc says a caller may.
• examples/parse-and-build-torrent: Builds a .torrent from in-memory content, parses it back, and derives a magnet link, using nothing but the three leaf crates a Rust consumer would reach for first: rlibtorrent-metainfo, rlibtorrent-magnet, rlibtorrent-types.
• examples/seed-and-download: Two engines in one process: one seeds a torrent, the other downloads it, over a real TCP socket on this machine's loopback interface.

How it is checked

• 15 fuzz targets feed the parsers generated input, looking for a crash or a hang.
• Oracles: two pinned libtorrent builds (2.0.14 and 1.2.20), rqbit and Transmission, driven as subprocesses, so a difference in behaviour shows up as a failing comparison.
• A deterministic lab: a virtual clock, a seeded random source and scripted peers, so a failure replays exactly.
• The race above, run on the bench PC against the released clients.

Licence

PolyForm Noncommercial 1.0.0: free to use, change and embed for any noncommercial purpose. A product a business sells or runs on it needs a commercial licence. Source-available, not OSI open source.

Terms used here

Tracker

The server that tells each client which other clients have the torrent. A client “announces” to it to join.

Announce

A client's request to the tracker: here I am, who else has this torrent?

Registered (Announce OK)

The tracker's first answer that accepts the client. Until then the client gets no peers from it.

Private torrent

A torrent flagged so that clients find peers only through its tracker: no DHT, no peer exchange, no local discovery. Private trackers depend on it to count every byte.

Tracker lag (T)

How long the race's tracker answers “unregistered” after the start, as a private tracker does while a new upload is still being processed. T=0 s: it accepts at once.

Seeder

A client that has the whole torrent and only uploads.

Swarm

Every client sharing one torrent at that moment.

Piece

The torrent's unit of data (1 MiB here). Each one is checked against its hash before it counts, so a client never shares a broken piece.

Upload share

What one racing client sent the other racing clients, as a share of everything they sent each other. The seeders' upload is not counted.

Median and range

The middle run, and the fastest and slowest. A median is not moved by one odd run; the range shows how much the runs differ.

Recheck

Reading a finished file back and checking every piece's hash, as a client does after a crash or when it is moved.

Peak private memory

The most memory the client's process held for itself at any moment of the run.

CPU time

Processor time the client used during the run, counted in cycles and expressed in seconds of one core.

Info hash

The hash that names a torrent; two clients mean the same torrent when it matches.

DHT

The distributed table clients use to find peers without a tracker (BEP 5).

Peer exchange (PEX)

Clients telling each other about further peers.

uTP

BitTorrent over UDP, with LEDBAT congestion control so it yields to other traffic.

Oracle

An independent implementation the engine's behaviour is compared against, here libtorrent, rqbit and Transmission.

Fuzz target

A test that feeds a parser endless generated input, looking for a crash or a hang.