Eine SRT-Verbindung kann erfolgreich aufgebaut werden und im Labor fehlerfrei übertragen, während wichtige technische Fragen offenbleiben. Was geschieht, wenn ein nicht blockierender UDP-Sendeaufruf auf lokalen Rückstau trifft? Bleibt eine Verlustmeldung korrekt, nachdem Steuerpakete zusammengefasst wurden? Kann eine Anwendung gepufferte Nachrichten noch lesen, nachdem sie einen redundanten Pfad geschlossen hat? Bekommt eine ereignisgesteuerte Event-Loop die Benachrichtigung, die sie braucht, um das Senden fortzusetzen?
Robotweax SRT 0.2.7, veröffentlicht am 2. Oktober 2026, konzentriert sich auf diese Fragen. Das Release stärkt Recovery, Verschlüsselungsübergänge, Verbindungsgruppen und das Laufzeitverhalten – und liefert Qualifikationsnachweise, die Entwicklungsteams vor einer Evaluierung in ihren eigenen Systemen prüfen können.
Für Unternehmen, die derzeit auf der SRT-Bibliothek von Haivision aufbauen, bietet Robotweax eine unabhängige C++20-Implementierung mit der vertrauten öffentlichen SRT-C-API. Das Referenzprofil für die Kompatibilität zielt auf SRT 1.5.7. So lässt sich eine weitere Implementierung anhand der Anforderungen der eigenen Anwendung bewerten – mit ausdrücklichen Supportgrenzen und reproduzierbaren Tests.
Die Versionsnummern beschreiben unterschiedliche Verträge:
| Vertrag | Robotweax SRT 0.2.7 |
|---|---|
| Projekt-Release | 0.2.7 |
| ABI-Linie der Robotweax-Shared-Library | 0.2 |
| Kompatible öffentliche SRT-API | 1.5.7 |
| Handshake-Generation für den produktiven Einsatz | HSv5 |
| Standardverschlüsselung | OpenSSL / AES-CTR |
| Optionale Verschlüsselungserweiterung | AES-GCM, ausdrücklich zu aktivieren |
Die Robotweax-ABI-Linie bedeutet keine binäre Austauschbarkeit mit der Bibliothek von Haivision.
Recovery bei lokalem Rückstau korrekt halten
Eine konkrete Verbesserung betrifft bestehende Verbindungen, bei denen der nicht blockierende UDP-Socket would_block zurückgibt.
Robotweax behält das kodierte Datagramm und wiederholt dieselben Bytes über den bestehenden Scheduler. Die Vorbereitung weiterer DATA- und FEC-Pakete pausiert, während die zurückgestellte Ausgabe abgearbeitet wird. Sendeabrechnung, Pacing, FEC-Zulassung und die Zähler für Verschlüsselungsschlüssel-Pakete werden erst fortgeschrieben, wenn UDP das Datagramm angenommen hat.
Für verschlüsselten Verkehr ist diese Unterscheidung wichtig: Die Wiederholung eines lokalen Sendeversuchs muss die ursprünglich geschützte Nutzlast erhalten. Sie muss auch spätere Ereignisse beachten. Ein bestätigtes Retransmission-Paket oder ein abgelaufenes DATA-Paket darf nicht allein deshalb erneut erscheinen, weil es auf Socket-Kapazität gewartet hat.
Die Warteschlange für zurückgestellte Pakete ist begrenzt. Dauerhafte Fehler und Überlastung führen weiterhin zu ausdrücklichen Fehlern. Deterministische Tests prüfen wiederholten Rückstau, Byte-Erhaltung, Ablauf, Abbruch, Entleerung sowie verschlüsselte Schlüsselrotation mit FEC. Diese Prüfungen belegen definiertes Verhalten bei injizierten Fehlern; sie belegen weder unbegrenzte Überlasttoleranz noch höheren Durchsatz. Der Backpressure-Vertrag beschreibt die Einzelheiten.
Das Release korrigiert außerdem ACK-Taktung und RTT-Abtastung, Invarianten der Verlustliste, periodische NAK-Verarbeitung, Empfangsfristen, Zeitstempel-Ursprünge und die Recovery über Sequenzlücken hinweg. Diese Änderungen zielen gemeinsam auf das Zusammenspiel von Recovery-Zustand und Transport-Timing.
Empfangene Nachrichten beim Schließen eines Gruppenpfads erhalten
Anwendungen mit redundanten Pfaden brauchen eine klare Unterscheidung zwischen dem Schließen einer Mitgliedsverbindung und dem Verwerfen von Daten, die bereits über sie empfangen wurden.
Version 0.2.7 erhält vollständige, lokal empfangene, noch ungelesene Nachrichten, wenn ein altes Gruppenmitglied ausdrücklich geschlossen wird. Die Aufbewahrung ist nach Paketanzahl, Nutzdaten-Bytes, Batch-Anzahl und Alter ungelesener Daten begrenzt. Kapazitäts-, Allokations- oder Ablaufprobleme werden als ausdrückliche Verbindungsfehler gemeldet.
Diese Warteschlange erhält empfangene Nachrichten; sie kann fehlende oder unvollständige Nachrichten nicht rekonstruieren.
Broadcast- und Backup-Gruppen erhalten zudem Korrekturen an Vorlagen für Mitgliedsoptionen, verspätetem Beitritt, Sende-Rückstau, Zustands-Snapshots und logischer Bereitschaft. Ein mitgliedsspezifischer GROUPMINSTABLETIMEO-Wert bleibt nicht unterstützt; Anwendungen müssen den dokumentierten gruppenweiten Vertrag verwenden.
Die jüngste Korrektur für die Aufbewahrung bestand 893 native Tests, 72 Sanitizer-Gruppentests und 24 bidirektionale UDP-Prefix-Fälle für Klartext, CTR, GCM, Broadcast, Backup sowie ausdrückliches Schließen und Behalten. Das sind Funktionsergebnisse, keine Garantien für Maximalkapazität oder reale WAN-Strecken.
Event-Loops und Verschlüsselungsübergänge
Für Anwendungen mit nicht blockierendem I/O muss sich Protokollkorrektheit auch in den Bereitschaftsbenachrichtigungen zeigen. Release 0.2.7 korrigiert das erneute Aktivieren von Sendebenachrichtigungen bei Edge-Triggering, Ereignisse zu Lese-Fristen, die Sperrreihenfolge bei Schließen und Rückstau sowie den Abschluss der Shard-Entleerung. Auch Callback-Bereinigung und Wiedereintritt wurden gehärtet.
Änderungen an der Verschlüsselung betreffen den Zustand optionaler Verschlüsselung, die Meldung des ausgehandelten Verfahrens, die Zulassung von Schlüssellängen, Rotationsbudgets und die Identität von Empfangsschlüsseln über Refresh und eine begrenzte Historie ausgemusterter Schlüssel hinweg.
Die Sicherheitsgrenze bleibt ausdrücklich benannt. AES-CTR bietet Vertraulichkeit ohne Authentifizierung der Nutzlast. Die optionale AES-GCM-Erweiterung authentifiziert DATA innerhalb ihres dokumentierten Umfangs, aber keine Laufzeit-Steuerpakete. Vollständiger Replay-Schutz für die langfristige Schlüsselverwaltung ist laut Issue #112 weiterhin offen. Dieses Release enthält kein ACP1-Wire/API-Profil.
Nachweise, die Entwicklungsteams prüfen können
Die CI für den finalen Release-Tag bestand ebenso wie die konfigurierten Integrationsprofile für FFmpeg, GStreamer, VLC und OBS. Sie qualifizieren bestimmte Source-Builds und Testszenarien, aber nicht automatisch beliebige installierte Anwendungs-Binaries.
Die Distributionsprüfungen umfassen Homebrew, sechs statische und dynamische vcpkg-Profile sowie Paket-Builds und Consumer unter Ubuntu 24.04 und Fedora 44.
Der Windows-SDK-Workflow baute zwölf OpenSSL-/BCrypt-Varianten für Win32, x64 und ARM64 in Debug- und Release-Konfigurationen. Beide finalen Installer sind von der Robotweax GmbH mit Authenticode signiert, wurden nach dem Signieren getestet und werden von Prüfsummen der signierten Dateien begleitet. Heruntergeladene Release-Assets wurden Byte für Byte mit den qualifizierten signierten Artefakten verglichen. BCrypt bleibt experimentell.
Eine qualifizierte Homebrew-Bottle ist für Apple Silicon unter macOS 15 verfügbar:
brew install robotweax/tap/robotweax-srtGezielte Linux-/Windows-Performance-Kampagnen und Messungen auf realen Netzwerkstrecken stehen noch aus. Das Release erhebt deshalb keinen allgemeinen Anspruch auf Vorteile bei CPU-Bedarf, Durchsatz oder Latenz.
Für eine technische Evaluierung sollten Sie mit dem tatsächlichen Integrationsvertrag Ihrer Anwendung beginnen:
- Erfassen Sie die benötigten API-Aufrufe, Socket-Optionen, Transportmodi, Verschlüsselungseinstellungen und das Gruppenverhalten.
- Bauen Sie Ihre Anwendung mit Robotweax und dessen namensraumspezifischen Paketmetadaten neu; verwenden Sie dabei nur einen SRT-Provider pro Anwendungsprozess.
- Testen Sie Ihre Szenarien für Paketverlust, Wiederverbindung, Rückstau, Schlüsselrotation und Herunterfahren.
- Messen Sie die Performance auf Ihrer Zielhardware und Ihren Netzwerkstrecken, bevor Sie über einen Rollout entscheiden.
Robotweax SRT ist weiterhin pre-1.0. Das Inventar der öffentlichen C-Exports ist gegenüber Robotweax 0.2.6 unverändert; direkte C++-Consumer aus dem Quellbaum müssen dagegen mit zueinander passenden Headern und Bibliotheken neu gebaut werden.
Robotweax SRT 0.2.7 herunterladen und die Release Notes mit Qualifikationsnachweisen lesen, um eine Evaluierung anhand der Anforderungen Ihrer Anwendung zu planen.