11 · Network failure, half-open detection and repair

Starting state

Verified peer on a live request/binding; socket, Network or one direction can fail independently.

Ordered events

1. Runtime → Engine

   Socket or binding loss closes affected links

2. Engine → Peer

   Otherwise direct signed ping/pong probes each second

3. Engine → Engine

   No matched round trip enters suspect then dead

4. Engine → Aware

   Emit scoped release_request with exact ownership tuple

5. Aware → Runtime

   Retry eligible desired peer with a new request incarnation

Fields and messages

LinkId, direct token/stamp, requestId/session/incarnation and failure reason.

Authorization and invariants

Valid media or heartbeat is not proof of a round trip; replayed/mismatched pong cannot refresh it. Stale release cannot kill a replacement binding.

Timers

Ping 1 s; suspect 3 s; dead 6 s; recovery two consecutive fresh pongs; retry 1/2/4/5 s, reset only after actual responsiveness.

Resource lifetime

Source key/replay retain ride lifetime; hop exporter and link ID change on reconnect. Shared responder request survives a single peer timeout.

What the rider sees

Bounded linkHealth/linkEvents and connection stages explain recovery; no blanket connected flag hides setup failure.

Failure branches

Hard current Network loss retires all binding owners; stale onLost is ignored; generic onUnavailable is not proof of resource exhaustion.

Resulting state

Failed peer retires; exact outgoing request is released/backed off; unrelated shared owners continue; new connection can synchronize state.

Evidence boundary

Deterministic directional-loss/deadline tests, real socket reconnect and JVM callback/retry ownership tests.