0 Fork 0

Files

T

Nils Andreas Svee 1ec82d8c56 docs: turn the root README into a project landing page

Reduce the root README to project discovery and navigation: what
irtt-rs is, its relationship to upstream IRTT (including a factual
capability comparison checked against upstream v0.9.2), installation,
a short quick start, and links out to detailed documentation. Detailed
CLI behavior, output/measurement semantics, continuous-mode memory
guidance, and server bind/session/negotiation semantics move into new
manpage-shaped docs under docs/ (irtt-rs, irtt-client, irtt-tui,
irtt-server), rewritten as operational guidance rather than copied
verbatim from the old README sections they replace.

2026-08-20 22:17:25 +07:00

2.5 KiB

Raw Blame History

irtt-rs

NAME

irtt-rs - IRTT-compatible multi-applet dispatcher

SYNOPSIS

irtt-rs client [OPTIONS] [[LABEL=]TARGET]...

irtt-rs tui [OPTIONS] [LABEL=]TARGET...

irtt-rs server [OPTIONS]

DESCRIPTION

irtt-rs is a multicall dispatcher: one binary that runs the client, TUI, or server applet depending on the subcommand given, or on the name it was invoked/copied as. It exists for router-friendly single-binary deployment; it does not add behavior beyond what irtt-client(1), irtt-tui(1), and irtt-server(1) already provide.

Each subcommand behaves exactly like its dedicated binary — irtt-rs client ... is equivalent to running irtt-client ... directly. See those manuals for target syntax, options, output, and exit behavior.

APPLET BINARY NAMES

The build also produces dedicated binaries: irtt-client, irtt-tui, and irtt-server. A dedicated binary always runs its own role, regardless of what it is invoked or copied as — it does not consult argv0 dispatch logic.

irtt-rs itself inspects argv0 first: if invoked (or symlinked/copied) under one of the recognized applet names — irtt-client, irtt-tui, irttd, or irtt-server — it runs that applet directly, without needing a subcommand. Any other name starting with irtt- (other than irtt-rs itself) is rejected as an unknown applet name before subcommand parsing is even attempted — irtt-custom server is a hard error, not a fallthrough. Only irtt-rs itself, or a name that doesn't start with irtt- at all, falls through to ordinary client/tui/server subcommand parsing.

FEATURE-DEPENDENT APPLET AVAILABILITY

Each applet is gated by a Cargo feature on the irtt-rs package: client, tui, server. All three are in the default feature set. A build with a feature disabled still produces the irtt-rs binary, but that applet is unavailable at runtime — running it (by subcommand or by binary name) reports which feature to rebuild with, and irtt-rs --help lists which applets the current build actually contains.

cargo install irtt-rs --locked --no-default-features --features client

RELATIONSHIP TO irtt-client, irtt-tui, irtt-server

irtt-rs is packaging and dispatch only. All probing, display, and server behavior lives in irtt-client(1), irtt-tui(1), and irtt-server(1) — consult those manuals for anything observable about running a probe or serving one.

2.5 KiB Raw Blame History