[06]entry 6 of 29
Trav
this entry is written twice, in full
- 1.in brief
async BitTorrent engine in Rust
- 2.in general
A headless BitTorrent engine with three front-ends.
- 3.in particular
One async engine core drives a terminal dashboard and a Tauri desktop app from a single shared snapshot.
- 1.in brief
a BitTorrent downloader, written from scratch
- 2.in general
One download engine with three different faces on it.
- 3.in particular
The engine runs on its own and feeds a terminal dashboard and a desktop app from a single live status.
context
Trav is a Rust1 workspace built around one headless engine (trav-core) and multiple interfaces: a Quantum terminal dashboard, a Nova desktop app (Tauri4 + Next.js5), and a CLI to bootstrap them. The design keeps networking entirely off the UI thread.
the problem
Implementing the BitTorrent protocol correctly is real systems work (bencode parsing, the peer wire protocol, piece management, trackers, DHT), and doing it async without ever stalling the interface that watches it.
what i built
- 1.
Async engine loop with command/event channels; bencode parsing, info-hash generation, rarest-first piece manager
- 2.
Peer wire protocol framing, HTTP/UDP trackers, magnet parsing, DHT/KRPC scaffolding
- 3.
Security throughout: jailed download paths, path sanitization, spawn_blocking SHA-1 verification, adaptive peer penalties and backoff
- 4.
A shared Arc<RwLock<EngineSnapshot>> exposes live metrics to both TUI and GUI with no blocking
- 5.
Bounded disk queue and an LRU FilePool to cap open file handles on multi-file torrents
outcome
A clean separation of engine from interface: the same non-blocking telemetry powers a dense ratatui dashboard with sparklines and a Tauri4 GUI with drag-and-drop and a system tray.
Networking stays off the UI thread: the TUI and the GUI read the same live telemetry, and neither stops drawing because a peer decided to misbehave.
context
Trav is one engine that does the downloading, with several interfaces sitting on top of it: a dense terminal dashboard, a desktop app, and a command line to start either. The whole point of the arrangement is that the network work never happens on the same thread that draws the window.
the problem
Implementing BitTorrent properly is real systems work: reading the file format, holding the conversation with other computers sharing the file, deciding which piece to ask for next, talking to the servers that coordinate it, and finding peers with no server at all. And doing every part of that without ever stalling the interface watching it.
what i built
- 1.
An engine that talks to everything at once, reads the torrent format, and asks for the rarest pieces first, which is what stops a download stranding at 99 per cent.
- 2.
The full conversation with other peers, both kinds of coordinating server, magnet links, and the beginnings of the peer-finding network that needs no server at all.
- 3.
Security throughout: a download cannot escape the folder it belongs in, a crafted filename cannot escape it either, checking a finished piece happens off the main thread, and peers that behave badly get backed away from rather than trusted again immediately.
- 4.
One shared live status that the terminal and the desktop app both read, arranged so neither can block the other while it does.
- 5.
A cap on how many files are held open at once, so a torrent containing thousands of them does not exhaust the machine.
outcome
A clean split between the engine and the things watching it: the same non-blocking status drives a dense terminal dashboard with live graphs and a desktop app with drag-and-drop and an icon in the system tray.
The network work stays off the drawing thread: both interfaces read the same live status, and neither stops updating because a peer decided to misbehave.