Crate sapflow_srt 

SRT for sapflow: live receiver/listener and bounded paced caller/sender.

Written from the SRT specification (draft-sharabayko-srt-01) and from watching real sessions on the wire (libsrt 1.5.4’s srt-live-transmit and the encoders in docs/interop.md); where the two differ, the wire wins and docs/reference.md says so.

Sans-IO, no async runtime: Listener takes datagrams with their source address and the time, and gives back datagrams to send, Events (a caller asking to connect, payloads in order, a connection closing) and when it next needs the time. The server owns the socket.

Layers:

• seq: 31-bit sequence numbers and 32-bit timestamps, both wrapping.
• packet: every packet type, parsed from and encoded to bytes.
• loss: the receiver’s loss list and when to ask again.
• rtt: round-trip time from ACK/ACKACK pairs.
• receiver: one connection: buffer, timestamp-based delivery with too-late drop, ACKs, NAKs, keepalives, idle timeout.
• listener: handshakes (version 5, SYN cookies keyed per process), stream ids, limits, and the connections.

Caller adds bounded, paced live sending. Live mode only: no file mode, rendezvous, groups or packet filters. Optional AES-128/256-CTR uses strict key negotiation and refresh. CTR does not authenticate media; control/stream IDs remain clear. See crypto for the supported profile.

Every byte that arrives is hostile until the application accepts the caller: nothing here indexes without a bound or trusts a length, and it is fuzzed (own_srt_packet, own_srt_listener).

Re-exports

pub use caller::Caller;

pub use caller::CallerCloseReason;

pub use caller::CallerConfig;

pub use caller::CallerEvent;

pub use caller::CallerStats;

pub use sender::SendConfig;

pub use sender::SendError;

pub use sender::SendStats;

pub use listener::Config;

pub use listener::ConnId;

pub use listener::Event;

pub use listener::Listener;

pub use listener::ListenerStats;

pub use listener::RejectCode;

pub use receiver::CloseReason;

pub use receiver::Stats;

Modules

caller

Live caller, written from draft-sharabayko-srt-01 sections 3.2.1 and 4.3.1 and our own packet/listener modules.

crypto

SRT AES-CTR/KM profile, from draft-sharabayko-srt-01 §§3.2.2,6.

listener

The listener: every datagram to the SRT port comes here. It answers handshakes (section 4.3.1), asks the application about each stream id, and passes later packets to their connection’s Receiver.

loss

The receiver’s loss list: sequence numbers not yet received, as ranges, each with when it was last asked for.

packet

SRT packets: parsing and encoding (draft-sharabayko-srt-01, section 3).

receiver

One connection’s receiving side, after the handshake: the receive buffer, timestamp-based delivery (TSBPD) with too-late packet drop, ACKs, NAKs, RTT, keepalives and the idle timeout.

rtt

Round-trip time from ACK/ACKACK pairs (section 4.10).

sender

Bounded live sending window (SRT draft sections 4.8 and 5.1).

seq

Sequence numbers (31 bits, wrapping) and packet timestamps (32 bits of microseconds, wrapping every 71.6 minutes).