Transport
A pluggable Transport trait — a deterministic in-memory implementation for simulation, and a framed TCP implementation for a real cluster.
Purpose
Raft nodes need to exchange typed RPC messages — RequestVote,
AppendEntries, InstallSnapshot, and their responses — over the network.
crates/raft puts that behind a single Transport trait so the exact same
message contract can be driven by two very different implementations: a
real socket for a live cluster, and a deterministic fake for tests. Neither
RaftCore itself nor the message types (rpc.rs's Message enum) know or
care which one is underneath.
Two implementations, one trait
The in-memory transport is a deterministic, seeded message bus built for reproducible multi-node testing. It supports fault injection — partitioning a node from the rest of the cluster, dropping messages, and delaying them — which is exactly the seam the chaos/Jepsen harness (Roadmap) will extend with richer fault scripts. A fixed seed is meant to reproduce a run exactly, which is what makes a failing test case replayable instead of a one-off flake.
The TCP transport is the real one: length-prefixed framed messages over a socket, with a small hand-rolled codec rather than a general-purpose RPC framework — deliberately dumb, because the pluggable seam exists to serve the test harness, not to grow into a feature-rich networking layer.
Where determinism actually lives
RaftCore's own test suite and the safety-invariant simulation
don't drive nodes over the async in-memory transport described above — they
use a synchronous, single-task message router built specifically for the
core's tests. That sidesteps a real subtlety: the async in-memory
transport's seed governs delivery timing (partition/drop/delay
scheduling), but doesn't itself impose an order on messages sent
concurrently by independent tasks — true determinism there needs either a
single controlling task or explicit seeded interleaving. RaftCore's
simulation gets full reproducibility by using a synchronous router driven
from one task; the async transport in this module is what the eventual node
driver and the chaos harness exercise, where that real-async, multi-task
shape is the point.
What's next
Wiring the transport into an async node event loop — the ticks,
inbound-message, and client-proposal loop that drives RaftCore against a
real clock — is node-driver work, not yet built. See
Overview for the core/driver split
and Roadmap for sequencing.