An SRT connection can establish successfully and transfer cleanly in a lab while leaving important engineering questions unanswered. What happens when a nonblocking UDP send encounters local backpressure? Does a loss report remain correct after control packets are coalesced? Can an application still read buffered messages after closing a redundant path? Does an edge-triggered event loop receive the notification it needs to resume sending?
Robotweax SRT 0.2.7, released on October 2, 2026, focuses on those questions. It strengthens recovery, encryption transitions, connection groups, and runtime lifecycle behavior—and provides qualification evidence engineers can inspect before evaluating it in their own systems.
For companies currently building on the Haivision SRT library, Robotweax offers an independent C++20 implementation with the familiar public SRT C API. Its reference compatibility profile targets SRT 1.5.7. The opportunity is to evaluate another implementation against the requirements of your application, with explicit support boundaries and reproducible tests.
The version numbers describe separate contracts:
| Contract | Robotweax SRT 0.2.7 |
|---|---|
| Project release | 0.2.7 |
| Robotweax shared-library ABI line | 0.2 |
| Compatible public SRT API | 1.5.7 |
| Production handshake generation | HSv5 |
| Default encryption | OpenSSL / AES-CTR |
| Optional encryption extension | AES-GCM, explicitly enabled |
The Robotweax ABI line does not establish binary interchangeability with Haivision’s library.
Keeping recovery correct under local backpressure
One concrete improvement concerns established connections whose nonblocking UDP socket returns would_block.
Robotweax retains the encoded datagram and retries the same bytes through its existing scheduler. Further DATA and FEC preparation pauses while deferred output drains. Send accounting, pacing, FEC admission, and encryption key packet counts advance only after UDP accepts the datagram.
That distinction matters for encrypted traffic: retrying a local send must preserve the original protected payload. It must also respect subsequent events. An acknowledged retransmission or expired DATA packet must not reappear simply because it was waiting for socket capacity.
The deferred queue is bounded. Permanent errors and overload still produce explicit failures. Deterministic tests exercise repeated backpressure, byte preservation, expiry, cancellation, drain behavior, and encrypted key rotation with FEC. These checks establish defined behavior under injected failures; they do not establish unlimited overload tolerance or higher throughput. The backpressure contract documents the details.
The release also corrects ACK cadence and RTT sampling, loss-list invariants, periodic NAK handling, receive deadlines, timestamp origins, and recovery across sequence gaps. Together, these changes target the interactions between recovery state and transport timing.
Preserving received messages when a group path closes
Applications using redundant paths need a clear distinction between closing a member connection and discarding data already received through it.
Version 0.2.7 preserves complete, locally received, unread messages when an old group member is explicitly closed. Retention is bounded by packet count, payload bytes, batch count, and unread age. Capacity, allocation, or expiry failures become explicit connection errors.
This queue preserves received messages; it cannot reconstruct missing or incomplete messages.
Broadcast and Backup groups also receive corrections to member option templates, late joins, send backpressure, state snapshots, and logical readiness. Member-specific GROUPMINSTABLETIMEO remains unsupported; applications must use the documented group-wide contract.
The latest retention correction passed 893 native tests, 72 sanitizer group tests, and 24 bidirectional UDP prefix cases spanning cleartext, CTR, GCM, Broadcast, Backup, and explicit close/keep behavior. These are functional results rather than maximum-capacity or real-WAN guarantees.
Event loops and encryption transitions
For applications using nonblocking I/O, protocol correctness must be reflected in readiness notifications. Release 0.2.7 corrects edge-triggered send rearming, readable-deadline events, close/backpressure lock ordering, and shard drain completion. It also hardens callback cleanup and reentry.
Encryption changes address optional-encryption state, negotiated cipher reporting, key-length admission, rotation budgets, and receive-key identity across refresh and bounded retired history.
The security boundary remains explicit. AES-CTR provides confidentiality without payload authentication. The optional AES-GCM extension authenticates DATA within its documented scope, but does not authenticate runtime control packets. Complete long-horizon key-management replay protection remains unresolved in issue #112. No ACP1 wire/API profile ships in this release.
Evidence engineers can inspect
The final release-tag CI passed, alongside the configured FFmpeg, GStreamer, VLC, and OBS integration profiles. These qualify specific source builds and test scenarios; they do not automatically qualify arbitrary installed application binaries.
Distribution checks cover Homebrew, six static/dynamic vcpkg profiles, and Ubuntu 24.04 and Fedora 44 package builds and consumers.
The Windows SDK workflow built twelve OpenSSL/BCrypt variants across Win32, x64, and ARM64 in Debug and Release configurations. Both final installers are Authenticode-signed by Robotweax GmbH, tested after signing, and accompanied by post-signing checksums. Downloaded release assets were compared byte-for-byte with the qualified signed artifacts. BCrypt remains experimental.
A qualified Homebrew bottle is available for Apple Silicon on macOS 15:
brew install robotweax/tap/robotweax-srtDedicated Linux/Windows performance campaigns and real-network-path measurements remain outstanding. The release therefore makes no general CPU, throughput, or latency advantage claim.
For an engineering evaluation, start with your actual integration contract:
- Inventory the API calls, socket options, transport modes, encryption settings, and group behavior your application requires.
- Rebuild against Robotweax using its namespaced package metadata, keeping one SRT provider per application process.
- Exercise your loss, reconnect, backpressure, rotation, and shutdown scenarios.
- Measure performance on your deployment hardware and network paths before making a rollout decision.
Robotweax SRT remains pre-1.0. Its public C export inventory is unchanged from Robotweax 0.2.6, while direct source-tree C++ consumers require rebuilding against matching headers and libraries.
Download Robotweax SRT 0.2.7 and inspect the release notes and qualification evidence to define an evaluation against your application’s requirements.