Skip to content

Bridges

Cross-host bridge primitives

Substrate primitives that ferry bytes between two AdaptiveRing instances on different hosts. Most bridges are a typed client + server pair gated behind a Cargo feature so callers compile only the bridges they use; the reliable-UDP transport is std-only with a sender / receiver pair.

Sens-O-Matic is the reliable FEC-UDP protocol, and its erasure code is a swappable detail (like a cipher suite); a unified endpoint also switches between the codes mid-stream on measured loss. It appears below once per code (block Reed-Solomon and sliding-window RLC) plus the unified auto-switch.

For an untrusted or lossy real-world WAN, the unified Sens-O-Matic endpoint is the default choice - it is encrypted (TLS 1.3 on both codes) and its adaptive FEC holds throughput and a bounded latency tail across the whole loss range, where the stream bridges below degrade under loss. Reach for QuicBridge when you want QUIC’s stream multiplexing / migration / 0-RTT, and the TCP bridges on a trusted link. (The standalone RS row is std-only and unencrypted; TLS on the RS stream comes via the unified endpoint, which AEAD-seals both codes.)

BridgeTransportCargo featureEncryptionRing typeIdle behavior
QuicBridgeQUIC over UDPquic-bridgeTLS 1.3 via rustlsAdaptiveRingtokio::task::yield_now on empty/full
TcpTlsBridgeTCP + rustls recordtcp-tls-bridgeTLS 1.3 via rustlsAdaptiveRingtokio::task::yield_now on empty/full
TcpBridgePlain TCPtcp-bridgeNoneAdaptiveRingtokio::task::yield_now on empty/full
BlockingTcpBridgePlain TCPtcp-bridgeNoneBlockingSpscRingKernel-park via cross-process waker (zero CPU at idle)
Sens-O-Matic / RSReliable UDP, block Reed-Solomonnone (std)Noneitem-level sender / receiverReceiver parks on read timeout; sender non-blocking
Sens-O-Matic / RLCReliable UDP, sliding-window RLCnone / tlsOptional TLS 1.3item-level sender / receiverPoll-driven sender + receiver
Sens-O-Matic / unified switchReliable UDP, RLC<->RS auto-switchnone / tlsOptional TLS 1.3item-level sender / receiverPoll-driven sender + receiver

The original bridges accept Arc<AdaptiveRing> as their producer (client side) / consumer (server side) ring; the substrate’s default-facing ring type composes through unchanged, and the bridges ride the shape-axis morph through AdaptiveRing automatically. BlockingTcpBridge is the sibling whose forwarder calls recv_blocking / send_blocking on a BlockingSpscRing via tokio::task::spawn_blocking; the worker thread parks kernel-side instead of yielding the runtime slice, so an idle bridge consumes zero CPU and a freshly-published item ships across the wire one wake + socket-write later.