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 process;
20pub mod promotion;
21mod raft;
22mod raft_promotion;
23pub mod reader;
24pub mod replication;
25pub mod response;
26pub mod server;
27mod uring_teardown;
28
29#[cfg(feature = "dpdk")]
30pub mod dpdk_response;
31#[cfg(feature = "dpdk")]
32pub mod dpdk_transport;
33
34// The two wire bounds an application's codecs have to fit: the widest
35// request frame the readers accept, and the widest response frame the
36// response stage can encode. Re-exported here so an application can
37// assert against them at compile time, next to the bounds it declares
38// (`AppEvent::MAX_ENCODED_SIZE` is the journal's; these are the wire's).
39pub use client_frames::MAX_FRAME_SIZE;
40pub use response::MAX_RESPONSE_BUF;
41
42/// Control-plane event the accept loop, reader, and response stage
43/// exchange. Transport-agnostic — the payload is a socket fd + writer,
44/// not an app event — so both build modes refer to the same type.
45pub enum ControlEvent {
46    Connected {
47        connection_id: u64,
48        fd: std::os::unix::io::RawFd,
49        writer: melin_wire_protocol::blocking::BlockingFrameWriter<Box<dyn std::io::Write + Send>>,
50    },
51    Disconnected {
52        connection_id: u64,
53    },
54    /// Reader → response: the input pipeline was full when this
55    /// connection's frame arrived; deliver a `ServerBusy` notice through
56    /// the normal egress path. Routed through the response stage so
57    /// exactly one thread ever writes a client socket — a reader-side
58    /// send could land between the two halves of a partially-flushed
59    /// response frame and permanently desync the client's length-prefix
60    /// framing (2026-08 io_uring audit, review finding F3).
61    PipelineBusy {
62        connection_id: u64,
63    },
64}
melin_server_runtime/lib.rs

melin_server_runtime/
lib.rs
