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.

halt

Refusing client writes while a node cannot honour durability.

layout

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

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. 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.