Crate melin_server_runtime 

Application-agnostic LMAX-pipeline server runtime.

Groups the application-agnostic parts of the Melin server: the accept loop, frame reader, ack-policy wiring, admin endpoint, replication, and the optional DPDK transport. Generic over A: Application — the binary supplies a concrete app via server::run (or server::run_dpdk under feature = "dpdk") along with caller-supplied StartupEvents, RequestDecoder, ResponseEncoder, and event- publisher fn.

The application-side wiring (the Application itself, its decoder and encoder, any event publisher) lives in the application’s own crate — see the examples under crates/examples/.

Modules

ack_policy

Operator-facing ack policy.

admin

Operator admin endpoint — single TCP listener for all server-side commands an operator may send.

client_auth

The client listener’s verdict on a challenge response.

connection_limit

The client connection cap, and the io_uring sizing derived from it.

early_reply

The answers a reader decides on without publishing the request, on their way to the response stage.

halt

Refusing client writes while a node cannot honour durability.

layout

Where each pipeline thread runs and how it waits there: the --cores layout.

policy_control

How an ack-policy change reaches the journal.

process

Process-level setup for latency-sensitive servers: signal handling and memory locking. Generic OS plumbing — no application coupling.

promotion

The replica → primary promotion request channel.

reader

io_uring-based multiplexed reader with multishot RECV.

replication

Replication — synchronous input-stream streaming from primary to replica.

response

io_uring-based response stage — routes matching output to connections via IORING_OP_SEND.

server

Server orchestrator — binds the accept loop, pipeline threads, and reader.

Structs

StartupEvents

Events the runtime journals as a node takes up the primary role, before it serves its first client.

Enums

ControlEvent

Control-plane event the accept loop, reader, and response stage exchange. Transport-agnostic — the payload is a socket fd + writer, not an app event — so both build modes refer to the same type.

Constants

MAX_FRAME_SIZE

Bound on one client request frame, after the 4-byte length prefix: the wire protocol’s, so a client library and a node agree on it by construction.

MAX_REQUEST_BODY

Bound on one request body — what an application’s RequestDecoder is handed after the runtime has read the tag and the request’s ID. Public so an application can check its widest request against it at compile time; see the re-export in the crate root. The wire protocol’s, the bound a client’s request framing enforces, so the two sides agree on it by construction.

MAX_RESPONSE_BODY

Bound on one application response body — what a ResponseEncoder may write for a single report or query response.