Skip to main content

Module server

Module server 

Source
Expand description

RTMP ingest server session state machine — connectcreateStreampublish (Adobe RTMP 1.0 §7.2, NetConnection/NetStream commands).

See docs/rtmp.md §2 (Handshake), §4 (Protocol Control Messages), §5.3 (User Control Messages), §7 (RTMP Message Types incl. Command Message), and transmux/docs/codec/flv.md (FLV header/tag layout, Adobe FLV v10.1 Annex E) for the wire layouts this module ties together.

ServerSession is the sans-IO publish ingest engine: feed it inbound bytes via ServerSession::handle_data, get back outbound bytes to write plus a list of typed ServerEvents. It drives, in order:

  1. the crate::handshake::Handshake sub-FSM (C0/C1/C2 → S0/S1/S2),
  2. the crate::chunk::ChunkAssembler/crate::chunk::ChunkWriter chunk-stream (de)assembly,
  3. crate::message::ProtocolControl/crate::message::UserControl interpretation and replies,
  4. crate::amf0::Command routing for the connect/createStream/ publish command sequence, and
  5. FLV tag emission for Audio(8)/Video(9)/Data-AMF0(18) messages received while publishing.

§Session state

Internally tracked as Init → Connected(app) → Publishing(stream_key) → Closed. The handshake phase itself is not duplicated in this enum — it is tracked by self.handshake.is_done() (querying crate::handshake::Handshake directly), so there is exactly one source of truth for “has the handshake finished”.

§Ack accounting

§5.4.3’s Acknowledgement sequence number is a plain modular u32 (truncating the running total byte count) — the spec is silent on wraparound behaviour for this field, so this is a documented implementation choice, not a spec requirement.

Two further implementation choices, not spec requirements:

  • At most one Acknowledgement is emitted per handle_data call, even if the input buffer crossed window_ack_size multiple times over (e.g. a single call carrying several times the window in bytes). The threshold check runs once, after all messages in that call have been dispatched, not once per window_ack_size-sized increment.
  • Handshake bytes are excluded from the Ack byte count: the running total only accumulates post-handshake (chunk-stream) bytes — bytes consumed while still inside the C0/C1/C2 ↔ S0/S1/S2 handshake exchange never reach the counter.

§Reply csid convention

Protocol control and User Control messages MUST/SHOULD use chunk stream id 2 (crate::message::CONTROL_CHUNK_STREAM_ID) — enforced already by crate::message::ProtocolControl::to_message and crate::message::UserControl::to_message. This module’s own outbound AMF0 command replies (_result/onStatus) use COMMAND_CHUNK_STREAM_ID (3) — a real-world convention (distinct from the reserved control csid), not a spec-mandated value: §5.3 leaves csid choice to the sender for anything other than protocol control/user control traffic.

Structs§

ServerConfig
Configuration for a ServerSession.
ServerSession
The sans-IO RTMP publish ingest server session (see the module doc).

Enums§

ServerEvent
Typed events ServerSession::handle_data surfaces to the caller.

Constants§

DEFAULT_CHUNK_SIZE
Default outbound chunk size we advertise via Set Chunk Size on connect (§5.4.1). Larger than the §5.3 wire default (128) to reduce chunk-header overhead for real audio/video payloads.
DEFAULT_PEER_BANDWIDTH
Default Set Peer Bandwidth value we advertise on connect (§5.4.5).
DEFAULT_WINDOW_ACK_SIZE
Default Window Acknowledgement Size we advertise on connect (§5.4.4), and the default threshold for our own inbound Ack accounting (§5.4.3).