Network pressure and session reuse v1

Finite loopback schedule · 5 September 2026

Results

Seven checks pass with four session slots and a deliberately smaller two-job verification queue. One writer completion is held after its real ledger operation. A partial-frame peer EOF is reclaimed while the writer remains busy. Two complete requests fill the queue; a third is closed without submission or journal growth.

Explicit local closes remove the queued sources and their pending jobs. Closing the in-flight source closes its socket but does not cancel or replace the ledger owner. A new connection reuses available capacity with a new, monotonically assigned source ID. When the old completion arrives, no response is prepared for that new source; the client also observes no stray response byte.

The replacement then admits a new claim. Replaying the earlier unacknowledged claim succeeds without another record. Three submitted operations produce two claims and 442 journal bytes. Session and queue counts finish at zero.

Model comparison

Four stable observations match the narrow Python owner model: full queue/refusal, closed sources with owner still active, old completion after slot reuse, and new admission plus replay. Four changed-observation controls detect excess queued work, owner cancellation, a stray response, and duplicate accounting. The earlier five checkpoint expectations still match their retained trace.

This is one controlled schedule, not arbitrary-interleaving exploration or a proof of fairness. Queue capacity is two to expose queue exhaustion before the four-slot session limit. The capacity limit is local and does not establish identity scarcity.

Close semantics and limits

The partial-frame EOF is produced by a real peer write-half-close. After a complete request, write-half-close remains valid: clients can stop sending and still await a response. The queued and in-flight close events are explicit node-side transport closures, not a claim that TCP reveals the remote application's full intent.

The gate delays completion notification after the ledger call. No actual stuck fsync, process crash or kernel cancellation is tested. Joining the owner remains required before recovery; in-flight cancellation never erases committed accounting. Prepared response counts and observed client bytes are distinct checks.

Reproduce

SKEIN_NETWORK_PRESSURE=1 cargo run --locked --offline --features peer-recovery --example admission_isolated > outputs/network-pressure.json
python3 model/network_owner.py outputs/network-pressure.json

Results, comparison and manifest are retained under docs/results/network-pressure-v1*. Existing profiles remain the default when the environment switch is absent. Next: exercise post-recovery service through the network owner, rather than only direct ledger replay, and expand scheduling coverage before adding commit lanes. No public admission service or Fly deployment is enabled.