Skip to main content

weir_client/
lib.rs

1//! Synchronous blocking client for the weir daemon.
2//!
3//! Connects over a Unix domain socket (or TCP + mutual TLS behind the `tls`
4//! feature) and exchanges frames using the weir wire protocol v1. Each method
5//! issues one request and reads one response — no pipelining. For concurrent
6//! producers, create one [`WeirClient`] per thread.
7//!
8//! # Platforms
9//!
10//! The Unix-socket transport is, unsurprisingly, Unix-only. **The TCP + mutual
11//! TLS transport is not** — it builds wherever rustls does, Windows included,
12//! as of 2.0.3. Before then it was gated on `unix` by accident: it lives in its
13//! own module but imported two types that happened to sit in the Unix one.
14//!
15//! # Throughput: one record per round-trip
16//!
17//! [`push`](WeirClient::push) is synchronous: it sends one frame and blocks for
18//! the ack before returning, so one connection carries one record at a time.
19//! What that costs depends on the tier, and the two are bounded by different
20//! things:
21//!
22//! - **`Buffered`** is round-trip bound. The daemon acks from memory, so the
23//!   ceiling is roughly `1 / RTT`.
24//! - **`Durable`** is fsync bound, not RTT bound. The ack waits on the daemon's
25//!   fsync, which dominates the round trip by orders of magnitude — batching at
26//!   the daemon amortises it across concurrent producers, which is why fanning
27//!   out helps this tier *more* than it helps `Buffered`.
28//!
29//! Measured on one machine (Apple M3 Max, Unix socket, 256-byte records): a bare
30//! AF_UNIX round trip is **~7 µs**, and a single client reaches **~32,000 rec/s
31//! `Buffered`** and **~5,700 rec/s `Durable`**. On a 2-vCPU CI runner the same
32//! figures are ~13,900 and ~3,700. Treat these as the shape of the problem, not
33//! as a spec: they move with hardware, filesystem, and record size. An earlier
34//! version of this paragraph quoted "~50 µs RTT" and "~20k rec/s", which matched
35//! neither tier on any machine we have measured.
36//!
37//! To go faster, **fan out across connections**: create one `WeirClient` per
38//! producer thread (they're independent and the daemon handles many
39//! concurrently). Ordering is only guaranteed within a single connection's
40//! sequential pushes, not across connections.
41//!
42//! **A pooled client needs no protocol change at all** — the wire protocol
43//! already permits several frames in flight on one connection, and fanning out
44//! across connections is measurable today: roughly 5× on `Buffered` at 16
45//! connections and 9× on `Durable` at 48. A built-in batched-push *frame* is the
46//! part that needs new wire machinery. An earlier version of this paragraph
47//! attributed the protocol cost to both and so steered readers away from the one
48//! option that already works.
49//!
50//! # Example
51//!
52//! ```no_run
53//! # #[cfg(unix)] {
54//! use weir_client::{WeirClient, Durability}; // Durability is re-exported from weir-core
55//!
56//! let mut client = WeirClient::connect("/run/weir/weir.sock").unwrap();
57//! client.push(b"hello world", Durability::Durable).unwrap();
58//! # }
59//! ```
60//!
61//! # Knowing *which* record you pushed
62//!
63//! [`push`](WeirClient::push) returns `()`: the record was accepted, and nothing
64//! more. [`push_tracked`](WeirClient::push_tracked) instead returns a
65//! [`RecordCoordinate`] — the buffer segment the record landed in, its index
66//! within that segment, and the `record_id` the downstream sink will see for it
67//! as its idempotency key. That is what lets a producer reconcile what it sent
68//! against what arrived, rather than carrying its own sequence inside the
69//! payload and reconciling server-side.
70//!
71//! ```no_run
72//! # #[cfg(unix)] {
73//! use weir_client::{WeirClient, Durability};
74//!
75//! let mut client = WeirClient::connect("/run/weir/weir.sock").unwrap();
76//! let at = client.push_tracked(b"hello world", Durability::Durable).unwrap();
77//! println!("{} record {} -> {}", at.segment(), at.index(), at.record_id_hex());
78//! # }
79//! ```
80//!
81//! It is a **buffer address, not a per-producer sequence**: other producers'
82//! records interleave, so your own indices have holes. See
83//! [`push_tracked`](WeirClient::push_tracked) for the full list of what it does
84//! and does not promise, including how to detect a daemon that predates it.
85//!
86//! # Ack vs. delivery
87//!
88//! A successful [`push`](WeirClient::push) means the record is **durably buffered
89//! at the requested [`Durability`] tier** — fsync'd to the write-ahead buffer for
90//! [`Durable`](Durability::Durable), in memory for
91//! [`Buffered`](Durability::Buffered). It does **not** mean the record has reached
92//! your downstream sink yet: the daemon drains buffered records to the sink in
93//! batches, only once a WAB segment seals (its size threshold, or daemon
94//! shutdown). For a small smoke test the sink may not be touched at all — watch
95//! `weir_records_ack_total` (acceptance), not the sink-commit metric, to confirm
96//! the daemon took your records.
97//!
98//! [`push_tracked`](WeirClient::push_tracked) does not change this. Its
99//! coordinate says *where the record will be read from*, not that it has been
100//! read — it is an address, not a delivery receipt.
101//!
102//! # Running the daemon
103//!
104//! This crate is the producer side; the daemon is the `weir-server` binary:
105//!
106//! ```text
107//! mkdir -p /run/weir/wab            # the daemon does not create its directories
108//! weir-server --wab-dir /run/weir/wab --socket-path /run/weir/weir.sock
109//! ```
110//!
111//! `--wab-dir` must already exist. On macOS, do not place the socket directly in
112//! `/tmp` (it is a symlink the hardened bind rejects) — use a dedicated `0700`
113//! directory. Run `weir-server --help` for the full option list.
114//!
115//! # Observability
116//!
117//! The daemon serves Prometheus metrics at `127.0.0.1:9185/metrics` by default.
118//! The counters a producer cares about are labelled by tier/reason, e.g.
119//! `weir_records_accepted_total{tier="durable"}`,
120//! `weir_records_ack_total{tier="durable"}`, and
121//! `weir_records_nack_total{tier="durable",reason="empty_payload"}`.
122#![deny(missing_docs)]
123
124/// Transport-agnostic client core. Split out of `unix` so that `tls` — which
125/// needs a `TcpStream` and rustls, and nothing Unix-specific — is gated on the
126/// feature alone rather than on the platform.
127mod client;
128
129pub use client::{BatchOutcome, ClientError, DefaultTransport, WeirClient};
130
131#[cfg(unix)]
132mod unix;
133
134/// Re-export of [`weir_core::Durability`] so the common producer path needs a
135/// single crate import (`weir_client::Durability`).
136pub use weir_core::Durability;
137
138/// Re-exported: the durable address [`WeirClient::push_tracked`] returns for an
139/// accepted record. Lives in `weir-core` because both ends of the socket build
140/// it from the same bytes.
141pub use weir_core::RecordCoordinate;
142
143/// Re-export of [`weir_core::NackReason`] — the payload of [`ClientError::Nack`].
144/// Re-exported so consumers can match on the reason (e.g. to distinguish the
145/// connection-closing Nacks) without taking a direct dependency on `weir-core`.
146pub use weir_core::NackReason;
147
148#[cfg(feature = "tls")]
149mod tls;
150
151#[cfg(feature = "tls")]
152pub use tls::{ClientTlsConfig, TlsStream};