Bounded sessions and output v1

Experimental component harness · 5 September 2026

What passed

Seven real loopback checks exercise a fixed four-slot session pool: four concurrent retained sessions, refusal and closure of the fifth, refusal of a second pending response, completion of a small response before its client reads, expiry cleanup, capacity reuse, and disconnected-session cleanup. Peak retained occupancy is observed from the pool; final occupancy is zero. No per-connection task is spawned.

Nine additional checks inject writer behavior into the same bounded output state used by the real sockets. They cover invalid response lengths, WouldBlock, progress by a healthy writer beside a blocked writer, fixed deadlines despite partial progress, expiry without another write, Interrupted, exact partial-write reassembly, zero writes, and broken pipes.

Resource and scheduling contract

Each slot holds at most one output with a fixed 128-byte array. The four slots therefore reserve 512 bytes of response arrays, excluding metadata, socket buffers, and client/test fixtures. This is a declared capacity, not process RAM. Responses must contain 1–128 bytes; a second pending response is refused without replacement.

Each scheduling turn visits every retained slot and attempts at most one nonblocking write per pending output. WouldBlock and Interrupted leave the cursor unchanged and yield service. Partial writes advance the cursor without resetting the deadline. Completion, expiry, or another output error closes the session. Local write completion means bytes reached the socket API, not that a peer received or accepted them. Lost-response replay remains a separate ledger responsibility.

The accept path temporarily owns one additional socket before rejecting it when all four slots are occupied. Thus the retained-session cap is four, while accepted server descriptors can briefly reach five. Listener backlog and kernel buffering are outside this component's cap. Session capacity alone offers no Sybil fairness: four silent peers can occupy all slots until expiration.

Reproduce and limits

cargo run --locked --offline --example admission_sessions

Results and a source/binary manifest are retained under docs/results/admission-sessions-v1.json. The harness uses one ephemeral loopback listener, finite clients, and injected monotonic scheduling times. Expiry assertions test deadline decisions rather than elapsed wall-clock accuracy.

A 34-byte synthetic response can fit in TCP buffers without a reading peer. That real-socket check does not establish saturated-output behavior. WouldBlock and partial-write schedules are explicitly injected through a Write implementation; no real TCP buffer saturation is claimed. Responses in this harness carry no admission authority and do not access a ledger.

Next: combine the session pool with bounded framing, preverification and the single ledger writer; check multi-client progress and cleanup across those boundaries. Real socket saturation and allocator/process measurements remain open, along with handshake limits, authentication, kernel buffer policy and independent review. This adds no production service or public ingress.