melin-server-runtime 0.20.0

Application-agnostic server runtime with accept loop, journaling, replication, and optional DPDK transport
Documentation 
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79

//! 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/`.

pub mod ack_policy;
pub mod admin;
mod buf_ring;
pub mod client_auth;
mod client_frames;
pub mod connection_limit;
mod durability_gate;
pub mod halt;
pub mod layout;
pub mod policy_control;
pub mod process;
pub mod promotion;
mod raft;
mod raft_promotion;
pub mod reader;
pub mod replication;
pub mod response;
mod response_frame;
pub mod server;
mod startup;
#[cfg(test)]
mod test_roles;
mod uring_teardown;

pub use startup::StartupEvents;

#[cfg(feature = "dpdk")]
pub mod dpdk_response;
#[cfg(feature = "dpdk")]
pub mod dpdk_transport;

// The two wire bounds an application's codecs have to fit: the widest
// request body the readers hand a decoder, and the widest response body
// the response stages give an encoder room for — both after the
// protocol's framing, which the runtime reads and writes itself.
// Re-exported here so an application can assert against them at compile
// time, next to the bounds it declares (`AppEvent::MAX_ENCODED_SIZE` is
// the journal's; these are the wire's). `MAX_FRAME_SIZE` is the whole
// request frame, for a program that reads client frames itself.
pub use client_frames::{MAX_FRAME_SIZE, MAX_REQUEST_BODY};
pub use response_frame::MAX_RESPONSE_BODY;

/// 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.
pub enum ControlEvent {
    Connected {
        connection_id: u64,
        fd: std::os::unix::io::RawFd,
        writer: melin_wire_protocol::blocking::BlockingFrameWriter<Box<dyn std::io::Write + Send>>,
    },
    Disconnected {
        connection_id: u64,
    },
    /// Reader → response: the input pipeline was full when this
    /// connection's frame arrived; deliver a `ServerBusy` notice through
    /// the normal egress path. Routed through the response stage so
    /// exactly one thread ever writes a client socket — a reader-side
    /// send could land between the two halves of a partially-flushed
    /// response frame and permanently desync the client's length-prefix
    /// framing (2026-08 io_uring audit, review finding F3).
    PipelineBusy {
        connection_id: u64,
    },
}