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.
irtt-proto
Low-level wire encoding and decoding for the IRTT-compatible protocol: request and reply structs, flags, negotiable parameters, varint/zigzag primitives, and HMAC-MD5 packet authentication. No sockets, no runtime, no session state.
Who should use this
Most applications should not depend on this crate directly. Use
irtt-client to run client sessions or
irtt-server to run a server; both build on
irtt-proto and provide session lifecycle, negotiation, and validated
configuration on top of it.
Reach for irtt-proto directly only if you are implementing another
IRTT-compatible client or server from scratch and need the raw packet layer.
Field values mirror the wire format closely rather than expressing policy:
Params::decode rejects malformed input, but direct construction plus
Params::encode performs no additional validation — callers are responsible
for validating values before sending them.
Documentation
Full API documentation is on docs.rs/irtt-proto.
Project
Part of irtt-rs, an independent Rust implementation of an IRTT-compatible protocol stack.