Ticketing Frame Structure
The length-prefixed binary framing that carries Raft RPCs. Unlike the client protocol's \n-terminated frames, the length is sent first and that many bytes are then read. Request-response pairs on a connection go back and forth sequentially, and the dialing side is always the requester.
Request (dialer → receiver)
Structurerefresh
Response (receiver → dialer)
Structurerefresh
| Field | Size | Content |
|---|---|---|
tag | u8 | RPC type — see RPC Types (request only) |
len | u32, big-endian | Byte length of the payload that follows |
payload | len bytes | An openraft type serialized in postcard format |
Connection Management Rules
lenis capped at 64 MiB (checked on receipt). Any frame over the limit, a malformed frame, an unknowntag, or a Raft processing error are all handled by closing the connection — the dialing side (openraft) reconnects and retries.- The dialing side reuses one connection per target node. On an I/O error, or if a round trip is cancelled partway through, that connection is discarded and a fresh one is dialed on the next call — a half-read stream is never reused in a misaligned state.
Terminology
- length-prefix — framing that sends the body's length first, then reads exactly that many bytes. No delimiter like
\nis needed, so arbitrary binary data can be carried as-is. - serialization — turning an in-memory struct into a byte sequence suitable for transport.
- RPC (remote procedure call) — a request-response pair that calls a function on another server over the network, as if calling it locally.