Nils Andreas Svee
56a2a653d0
Each published crate (irtt-rs, irtt-client, irtt-server, irtt-stats, irtt-proto) now points crates.io at its own README instead of inheriting the root project README via the workspace-wide readme default, which is removed. Each crate README is a short landing page: what the crate is, who should use it, which sibling crate to use instead if this isn't the right abstraction level, and links to docs.rs and the main repository. Add real Cargo example targets teaching irtt-client's blocking/Tokio/ managed API tiers, a basic and a multi-listener irtt-server example, and an irtt-stats example contrasting finite vs continuous retention. irtt-proto intentionally has none. Update each crate's top-level rustdoc to explain its API-tier choices and point at the examples, and enable docs.rs rustdoc example scraping for irtt-client and irtt-server (via doc-scrape-examples on each example target, needed because the crate has dev-dependencies). The client examples are caller-paced against next_send_deadline() rather than sending on every loop iteration, bound their receive wait by the next send/timeout deadline instead of awaiting indefinitely, poll timeouts on a short fixed cadence, and surface send/receive/close errors instead of discarding them via unwrap_or_default()/if-let-Ok -- so they demonstrate correct pacing and terminate/report cleanly rather than racing the server, hanging on a lost reply, or silently dropping a failed final close.
1.6 KiB
irtt-stats
Statistics aggregation over irtt-client
events: loss/duplicate/late accounting, RTT and one-way-delay timing, and
inter-packet delay variation (IPDV), as cumulative and rolling snapshots.
Relationship to irtt-client
This crate does not open sessions or drive sockets. Feed it the ClientEvent
stream produced by an irtt-client Client, AsyncClient, or managed
session via StatsCollector::process, and read back a Snapshot.
A StatsCollector has one sequence/IPDV namespace and one packet count, both
scoped to a single target. A managed session covering multiple targets needs
one collector per target — as the irtt-rs CLI does — since a target's
sequence numbers start over at zero and feeding two targets into one
collector would pair up unrelated probes.
Retention modes
StatsConfig::finite() retains exact timing samples for its cumulative
snapshot, so every metric with samples reports an exact median there —
retention grows with the probe count. StatsConfig::continuous() keeps
bounded running statistics instead (no exact median) plus a bounded
4096-entry adjacent-sequence IPDV store per target, for long-running or
unbounded sessions. Rolling-window snapshots are always running-only and
report no medians, whichever StatsConfig produced them.
See examples/ in the repository for a runnable comparison of both modes.
Documentation
Full API documentation is on docs.rs/irtt-stats.
Project
Part of irtt-rs, an independent Rust implementation of an IRTT-compatible protocol stack.