Module handshake 

RTMP handshake — C0/C1/C2 and S0/S1/S2 (Adobe RTMP 1.0 §5.2).

See docs/rtmp.md §2 (Handshake) for the wire layout: C0/S0 (§5.2.2), C1/S1 (§5.2.3), C2/S2 (§5.2.4), and the handshake sequence diagram (§5.2.5).

Scope: simple handshake only

This module implements only the simple (plain) handshake described by §5.2 itself: C0/C1/C2 and S0/S1/S2 carry no HMAC-SHA256 digest and no “complex handshake” key-exchange scheme (that scheme is an Adobe Flash Media Server addition, not part of the RTMP 1.0 spec text transcribed in docs/rtmp.md). This is sufficient for interoperating with real-world publishers such as ffmpeg and OBS Studio, which fall back to (or always use) the simple handshake for rtmp:// publish. Complex-handshake support is out of scope for this crate.

No wall clock in the sans-IO core

This crate has no socket or clock of its own (see the crate-root sans-IO contract doc). time in S1 and time2 in S2 are therefore not read from a real clock: Handshake::new uses 0 for both and a fixed, non-cryptographic filler pattern for S1’s random bytes (see default_random_fill); Handshake::with_time_and_random lets a caller supply real values instead. Per §5.2.3/§5.2.4 neither field is required to be meaningful (the spec itself calls the bandwidth estimate they enable “unlikely to be useful”), and no rand-style dependency is pulled in to generate them.

Structs

EchoPacket

C2 (client→server) or S2 (server→client): the 1536-byte near-echo packet (§5.2.4).

Handshake

Sans-IO server-side RTMP handshake driver (§5.2, simple handshake only — see the module doc).

HandshakePacket

C1 (client→server) or S1 (server→client): the 1536-byte time/zero/random handshake packet (§5.2.3).

Version

C0 (client→server) or S0 (server→client): the 1-byte RTMP version (§5.2.2).

Constants

HANDSHAKE_PACKET_LEN

Wire length in bytes of C1/S1 and C2/S2 (§5.2.3/§5.2.4): 1536.

RTMP_VERSION

RTMP version this handshake implements/advertises (§5.2.2): 3.

Functions

default_random_fill

A fixed, non-cryptographic 1528-byte fill pattern for a server’s own S1 random bytes when the caller has no specific bytes to supply. Per §5.2.3 the field only needs to “distinguish this handshake from the peer’s” — no cryptographic randomness is required, so a deterministic repeating byte pattern is spec-conformant and keeps this crate free of a rand-style dependency.