Skip to main content

Module serve

Module serve 

Source
Expand description

One connection, from hello to hangup — and the accept loop that owns them.

What is served here is the request/response surface: the readiness answers, the one mutation path, and the reads — a projection by id, a projection page, and a page of the log. Every one of them is a question with an answer, which is what makes them one layer: a request goes out, a response comes back on the same request_id, and nothing arrives that was not asked for.

Subscriptions are the other half, and they are why a connection is two loops instead of one. A batch is a frame the client did not individually request, so it cannot be written by the code that answers requests: one loop owns the write half and takes work from two queues, responses before batches. What a subscription then DOES lives in subscribe — this layer admits one, bounds how many a connection may hold, and writes what they produce.

Blob transfer is here too, and it is thinner than it looks: the port already owns staging, digest verification, dedup, and encryption, so what this layer adds is the wire’s own concerns — base64 in and out, a bound on a chunk, and a clamp on a read.

Pages are cut by BYTES, not rows. The frame limit is the real bound and a row count cannot respect it — see [PAGE_BYTE_BUDGET].

No wildcard arm anywhere: every request is matched by name, so the compiler has to notice when the protocol grows one.

Structs§

Daemon
What a connection needs to answer the sealed surface.
Stopped
What a clean stop managed to do, for the caller to report.

Constants§

DRAIN_TIMEOUT_SECS
How long shutdown waits for connections that are mid-request.

Functions§

run
Accept until shutdown resolves, then stop accepting, drain, and checkpoint.
serve_connection
Drive one connection: handshake, then requests until the peer hangs up.
serve_stream
One UnixStream, served. The split is here rather than in serve_connection so the codec stays testable over any pair of pipes.