A video stream, a sequence of commands and a continuous series of sensor readings place different demands on a transport library. For a stream, freshness may matter more than delivery of every packet. A command, by contrast, needs to arrive intact and in the correct order. For measurements, a late retransmission may be less useful than the next current sample.
Robotweax SRT 0.2.8, released on October 8, 2026, makes these differences explicit with two selectable profiles: Control for ordered application messages and Sensor for time-sensitive, independent samples. It also adds optional session authentication version 2. None of these profiles silently replaces the existing Live or File modes.
The version numbers describe separate contracts: the project release is 0.2.8, the Robotweax shared-library C ABI line remains 0.2, and the compatible public SRT API targets 1.5.7. OpenSSL with AES-CTR remains the default. GCM and session authentication require explicit activation.
| Component | Intended data | Delivery and important limit |
|---|---|---|
| Control | Commands and discrete application messages | Complete and in send order; successful transport does not confirm command execution. |
| Sensor | Independent current samples and telemetry | No ARQ retransmission; fixed FEC can recover one loss per group of four, but not every missing sample. |
| Session authentication v2 | Key management and FEC parity | Checks bound to the specific session; not a substitute for separate GCM authentication of payload DATA. |
Control: complete messages in send order
The Control profile preserves message boundaries. An application can send one command as one message even when the library must spread it across several packets. The peer releases it as a complete message only after the required earlier packets are available.
Control uses File-mode flow control, NAK recovery and retransmission timeouts. Timed Live delivery and too-late packet dropping are disabled. This suits a sequence such as “set a parameter, then start an action”, where completeness and order matter.
The contract stops at the transport boundary, however. A successful send call initially means only that the message entered the bounded local send buffer. If the sender must know whether a machine or application actually executed the command, the application needs its own acknowledgement. Safe retries after a disconnect also require application-level command identifiers and handling of commands already executed. Control does not promise exactly-once execution across reconnects.
Both endpoints must select Control before connection setup. A versioned profile identity is checked during the handshake; an incompatible peer cannot silently establish a Control connection. Matching builds can explicitly configure AES-GCM for authenticated payloads. The version-pinned Control documentation covers the API, size limits and configuration.
Sensor: current samples without retransmission delay
The Sensor profile is intended for independent position, state or telemetry samples. It does not use ARQ retransmission or timed Live delivery through TSBPD. A lost sample therefore does not introduce a wait for its later retransmission.
Instead, the fixed profile uses forward error correction: one parity packet is generated for each four DATA packets. If exactly one DATA packet in such a group is lost, and the others plus parity are available, the receiver can reconstruct it. Multiple losses or missing parity may still leave samples unavailable. The profile does not guarantee gap-free delivery.
Each Sensor message must contain one complete sample and fit the configured packet payload; larger messages are not fragmented automatically. After FEC reconstruction, receive order may differ from send order. Applications that need the newest state should therefore include timestamps or monotonically increasing sample identifiers.
Sensor also requires matching configuration on both peers. Optional GCM authenticates directly received and reconstructed payloads before delivery to the application. The Sensor and FEC documentation describes packet limits and failure cases.
Session authentication v2: binding keys to a connection
Optional session authentication adds a cryptographic proof involving fresh random values from both peers, their socket identities and their roles. Recorded key-management messages from another session therefore cannot install keys in a new protected connection. Direction-separated counters reject stale key controls while allowing identical retries used to recover from packet loss.
Version 2 also authenticates FEC parity headers and payloads before they can change decoder state. These protections have distinct scopes: GCM authenticates payload DATA; session authentication protects session-bound key management and FEC parity. AES-CTR alone still does not provide DATA integrity. Ordinary ACK, NAK and shutdown messages, as well as some handshake fields, are not covered by this extension.
The feature is off by default. Caller and Listener must both enable it, configure a passphrase and enforce encryption. Without matching support, setup fails rather than silently falling back to a weaker profile. The enabled profile is not compatible with Haivision peers and does not support Rendezvous. The session-authentication documentation also names further limits, including the absence of forward secrecy and the need for independent cryptographic review.
Further changes and qualification
Version 0.2.8 rejects unrepresentable buffer sizes, invalid FEC input and conflicting handshake or profile configurations earlier. Budgets for cryptographic work during setup and for large NAK or deferred packet-drop lists limit work per runtime service turn.
Focused fixes also cover failed asynchronous connection diagnostics, ACK progress in Backup groups, callback retirement, keepalives during source pauses and forward progress after short network outages. A significant Live-delivery limit remains when peers advertise periodic NAKs: the final lost packet, or a lost burst before a source pause, is not guaranteed to recover. Use File mode and its timeout recovery for complete finite transfers.
Qualification of the published tag includes release CI and integrations, package consumers, Linux packages and Windows SDK qualification. Both Windows installers were rebuilt independently, signed and tested as signed files. Those checks qualify the described builds and scenarios, not every target machine, WAN path or application automatically.
Robotweax SRT remains pre-1.0. Teams should test the profiles, peers, encryption settings and failure cases their own deployment requires. Direct source-tree C++ consumers must rebuild with matching headers and libraries; the public C ABI line remains 0.2.
Download Robotweax SRT 0.2.8 · Read release notes and known limits