hardening: no concurrent-connection cap in shared mode (accept is unbounded)

[MDA2AV]

Severity: medium (high if deployed directly internet-facing rather than behind an LB/proxy).

Status 2026-09-20 (main @ 47eba14, shipped 0.14.239): the idle/keep-alive half of this issue is DONE — see #236. TcpOptions.IdleTimeoutMs and SendTimeoutMs both default to 60s, swept on the reactor's existing ~250ms ticker, mirroring QuicSweep. It also grew a clock the original body did not ask for: a connection with a flush outstanding is not idle but SENDING, so the send clock governs it, and a peer that keeps sending while it has stopped reading refreshes the idle stamp forever and is only catchable that way. This issue is now retargeted to the half that remains.

Problem — no concurrent-connection cap in shared mode

Track grows the connection table without bound and multishot accept is always re-armed, so the only backstop in shared mode is RLIMIT_NOFILE:

// src/ioxide/Reactor/Reactor.cs:139
private void Track(int fd, TcpConnection conn)
{
    if (fd >= _connections.Length)
    {
        int newLength = _connections.Length;
        while (newLength <= fd) newLength *= 2;
        Array.Resize(ref _connections, newLength);
    }
    _connections[fd] = conn;
}

Incremental mode has a cap and sheds at it (Reactor.Tcp.cs:231, since #92), because a gid is a hard-capped resource. Shared mode has nothing: ServerConfig.MaxConnections (ServerConfig.cs:69) lives on IncrementalOptions and is consumed only by the gid path, and TcpOptions.PoolMax caps the pool of connection OBJECTS, not live connections.

Reaching RLIMIT_NOFILE is not a graceful failure either: accept re-arms immediately on EMFILE, which pins the reactor at 100% CPU and logs millions of lines a second (#222).

The decision this needs

At the cap, either:

• shed — close on accept, which is what incremental does today and is a one-line mirror of it; or
• pause the accept re-arm until the count drops back below, which is real backpressure but needs the reactor to remember to re-arm, so it is a new piece of state rather than a branch.

Shedding is consistent with existing behaviour and cheap. Pausing is kinder to clients and to an LB's health checks. Worth deciding before writing either.

Notes

• The counter can hang off the same places the idle sweep already touches; no new bookkeeping on the recv or send path.
• Whatever the cap does, it should be observable — observability: per-reactor counters (ENOBUFS, overflows, accepts, sheds, pool hit rate) #101 (per-reactor counters) is where a "shed" count belongs.
• RLIMIT_NOFILE is per process, not per reactor, so a per-reactor cap has to be sized against the fleet rather than the limit.

[MDA2AV]

Retitled and rewrote the body, because half of this shipped and the title was promising something already done.

Done — the idle/keep-alive half, in #236, released in 0.14.239. TcpOptions.IdleTimeoutMs and SendTimeoutMs, both 60s by default, 0 disables, swept on the reactor's existing ~250ms ticker exactly as this issue suggested (QuicSweep mirrored). Teardown is shutdown() + MarkClosed(), leaving the refcounting to the completions that already run, so the reactor's ref is never released while a SEND still points into the connection's slab.

One thing the original body did not anticipate, which came out of building it: two clocks are needed, not one. A connection with a flush outstanding is not idle, it is sending — so the send clock governs it and the idle one does not, or a large response to a slow peer gets reaped for making no inbound progress. And the idle clock cannot cover a stall on its own, because a peer that keeps SENDING while it has stopped READING refreshes the idle stamp on every inbound completion. That shape — a websocket written from a background task — is the reported case in #234, and only the send clock catches it.

Remaining — the cap, which is what the body now describes. Verified against main @ 47eba14: Track still doubles the table with no ceiling, MaxConnections is still on IncrementalOptions and consumed only by the gid path, PoolMax still caps pooled objects rather than live connections.

It is left open rather than split because it still needs a decision before anyone writes it: shed at accept, or pause the accept re-arm. That is in the body now.