Skip to main content

Module liveness

Module liveness 

Source
Expand description

Path-liveness decision logic (Phase 4 / P4.3).

A purely-functional, async-free, Duration-only decision so the threshold logic is exhaustively unit-testable without standing up the data pump. The pump gathers the live signals each heartbeat and applies the returned verdict.

Liveness signal (design §D4): N×PTO of inbound silence while we have outstanding unacked reliable data → the path is down. The inflight > 0 gate is what keeps a slow-but-alive or genuinely-idle path from false-tripping — we only declare a path down when we are expecting a response.

A purely-passive receiver (download-only, sending only ACKs) has nothing in flight, so the inactivity sweep alone would never trip for it. Direction #3 closes that gap with an idle keep-alive PING (should_send_keepalive): when a Connected session has been idle for keepalive_interval, the pump emits a small ENCRYPTED | KEEPALIVE packet. That PING is in-flight until the peer PONGs it, so the very same inflight > 0 sweep now detects a dead downstream on a download-only path — and the PONG refreshes the peer’s activity timer symmetrically.

Structs§

LivenessConfig
Tunables for path-down / session-death detection (Phase 4 / P4.3).

Enums§

LivenessVerdict
The transition implied by one liveness evaluation. The caller maps it onto the session state machine (ConnectedMigratingDead).

Functions§

liveness_verdict
Decide the liveness transition from the current signals (pure).
should_send_keepalive
Decide whether an idle Connected session should emit a keep-alive PING now (Direction #3 — download-only liveness). Pure, so the cadence gate is unit- testable without the data pump.