melin_server_runtime/lib.rs
1//! Application-agnostic LMAX-pipeline server runtime.
2//!
3//! Groups the application-agnostic parts of the Melin server: the
4//! accept loop, frame reader, ack-policy wiring, admin
5//! endpoint, replication, and the optional DPDK transport. Generic
6//! over `A: Application` — the binary supplies a concrete app via
7//! [`server::run`] (or `server::run_dpdk` under `feature = "dpdk"`) along with caller-supplied
8//! `AppFactory`, `RequestDecoder`, `ResponseEncoder`, and event-
9//! publisher fn.
10//!
11//! The trading-side wiring (`ServerApp`, `ExchangeRequestDecoder`,
12//! `ExchangeResponseEncoder`, market-data firehose) lives in the
13//! separate `melin-server` crate.
14
15pub mod ack_policy;
16pub mod admin;
17mod buf_ring;
18mod client_frames;
19pub mod layout;
20pub mod process;
21pub mod promotion;
22mod raft;
23mod raft_promotion;
24pub mod reader;
25pub mod replication;
26pub mod response;
27pub mod server;
28mod uring_teardown;
29
30#[cfg(feature = "dpdk")]
31pub mod dpdk_response;
32#[cfg(feature = "dpdk")]
33pub mod dpdk_transport;
34
35// The two wire bounds an application's codecs have to fit: the widest
36// request frame the readers accept, and the widest response frame the
37// response stage can encode. Re-exported here so an application can
38// assert against them at compile time, next to the bounds it declares
39// (`AppEvent::MAX_ENCODED_SIZE` is the journal's; these are the wire's).
40pub use client_frames::MAX_FRAME_SIZE;
41pub use response::MAX_RESPONSE_BUF;
42
43/// Control-plane event the accept loop, reader, and response stage
44/// exchange. Transport-agnostic — the payload is a socket fd + writer,
45/// not an app event — so both build modes refer to the same type.
46pub enum ControlEvent {
47 Connected {
48 connection_id: u64,
49 fd: std::os::unix::io::RawFd,
50 writer: melin_wire_protocol::blocking::BlockingFrameWriter<Box<dyn std::io::Write + Send>>,
51 },
52 Disconnected {
53 connection_id: u64,
54 },
55 /// Reader → response: the input pipeline was full when this
56 /// connection's frame arrived; deliver a `ServerBusy` notice through
57 /// the normal egress path. Routed through the response stage so
58 /// exactly one thread ever writes a client socket — a reader-side
59 /// send could land between the two halves of a partially-flushed
60 /// response frame and permanently desync the client's length-prefix
61 /// framing (2026-08 io_uring audit, review finding F3).
62 PipelineBusy {
63 connection_id: u64,
64 },
65}