Expand description
RTMP ingest server session state machine — connect → createStream →
publish (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:
- the
crate::handshake::Handshakesub-FSM (C0/C1/C2 → S0/S1/S2), - the
crate::chunk::ChunkAssembler/crate::chunk::ChunkWriterchunk-stream (de)assembly, crate::message::ProtocolControl/crate::message::UserControlinterpretation and replies,crate::amf0::Commandrouting for theconnect/createStream/publishcommand sequence, and- 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_datacall, even if the input buffer crossedwindow_ack_sizemultiple 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 perwindow_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§
- Server
Config - Configuration for a
ServerSession. - Server
Session - The sans-IO RTMP publish ingest server session (see the module doc).
Enums§
- Server
Event - Typed events
ServerSession::handle_datasurfaces 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).