Module stream 

Available on crate feature std only.

Phantom Protocol - Stream Management

Independently-flow-controlled, reliability-segmented data channels multiplexed within one session. Each Stream owns its own send/receive buffers, gap-free reliable offset space (A.5), SACK-driven loss detection (RFC 9002), RFC-6298 RTO estimator, and credit-based flow-control windows. Per-stream sequencing means a stall or loss on one stream does not head-of-line-block any other stream (HoL blocking still applies within a stream — reliable data is delivered strictly in send order via accept_in_order).

Structs

LostSegment

One segment newly declared lost by Stream::on_sack’s RFC-9002 loss detector (L1-B) — still buffered, now flagged for fast-retransmit.

OutboundSegment

One segment handed back by Stream::poll_send for transmission.

RetiredSegment

One reliable segment retired by Stream::on_sack — a segment whose sequence a received SACK covered and which has now been removed from the send buffer.

SackResult

Outcome of processing a received SACK against the send buffer.

Stream

Stream - multiplexed data channel within a session

Enums

StreamState

Stream state

Constants

INITIAL_STREAM_WINDOW

Initial per-stream send window — caps how many bytes the local side will put on the wire before receiving a WINDOW_UPDATE from the peer. 64 KiB matches QUIC’s stream initial-window default.

MAX_RECV_REORDER_BYTES

Per-stream byte budget for the out-of-order reorder buffer (H-3), tied to the flow-control window. A compliant peer keeps in-flight (hence reorderable) data within ~one INITIAL_STREAM_WINDOW; the 2× headroom absorbs a boundary segment. A future hole that would push the buffered total past this is refused (dropped → retransmitted via the “refused segment is not SACKed” contract), so per-stream reorder memory is bounded regardless of the per-entry frame size (~253 KiB UDP / 4 MiB TCP) — the entry cap alone is not, since one entry can dwarf the window.

MAX_SEND_WINDOW

Hard ceiling on the credit-based send window. WINDOW_UPDATE frames add relative credit; this caps the accumulated window so a peer that floods inflated credits cannot overflow the counter. A compliant peer never grants more than ~one INITIAL_STREAM_WINDOW of outstanding credit, so the cap is only a misbehaving-peer guard (the receiver’s own delivery HARD_CAP is the real bound on buffering).