Ein Videostream, eine Befehlsfolge und laufend eintreffende Sensordaten stellen unterschiedliche Anforderungen an eine Transportbibliothek. Für einen Stream kann Aktualität wichtiger sein als die vollständige Zustellung jedes Pakets. Ein Befehl muss dagegen vollständig und in der richtigen Reihenfolge ankommen. Bei Messwerten kann eine verspätete Wiederholung weniger nützen als der nächste aktuelle Wert.
Robotweax SRT 0.2.8, veröffentlicht am 8. Oktober 2026, macht diese Unterschiede mit zwei ausdrücklich wählbaren Profilen sichtbar: Control für geordnete Anwendungsnachrichten und Sensor für zeitkritische, unabhängige Messwerte. Hinzu kommt eine optionale Session-Authentifizierung in Version 2. Keines dieser Profile ersetzt stillschweigend die bestehenden Live- oder File-Modi.
Die Versionsnummern beschreiben getrennte Verträge: Das Projekt-Release ist 0.2.8, die C-ABI-Linie der Robotweax-Shared-Library bleibt 0.2 und die kompatible öffentliche SRT-API zielt auf 1.5.7. OpenSSL mit AES-CTR bleibt die Standardeinstellung. GCM und Session-Authentifizierung müssen ausdrücklich aktiviert werden.
| Baustein | Für welche Daten? | Zustellung und wichtige Grenze |
|---|---|---|
| Control | Befehle und zusammengehörige Anwendungsnachrichten | Vollständig und in Sendereihenfolge; eine erfolgreiche Übertragung bestätigt nicht die Ausführung des Befehls. |
| Sensor | Unabhängige, aktuelle Messwerte und Telemetrie | Keine ARQ-Wiederholung; feste FEC kann einen Verlust pro Vierergruppe rekonstruieren, aber nicht jeden Ausfall verhindern. |
| Session-Authentifizierung v2 | Schlüsselaustausch und FEC-Parität | An die konkrete Sitzung gebundene Prüfung; kein Ersatz für die separate GCM-Authentifizierung der Nutzdaten. |
Control: Nachrichten vollständig und geordnet übertragen
Das Control-Profil erhält Nachrichtengrenzen. Eine Anwendung kann einen Befehl als eine Nachricht senden, selbst wenn die Bibliothek ihn für die Übertragung auf mehrere Pakete verteilen muss. Die Gegenstelle stellt ihn erst als zusammengehörige Nachricht bereit, nachdem die benötigten früheren Pakete vorliegen.
Control verwendet die Flusskontrolle sowie NAK- und Timeout-Recovery des File-Modus. Die zeitgesteuerte Live-Auslieferung und das Verwerfen zu spät eintreffender Pakete sind deaktiviert. Das eignet sich beispielsweise für eine Folge „Parameter setzen, dann Aktion starten“, bei der Vollständigkeit und Reihenfolge entscheidend sind.
Der Vertrag endet jedoch an der Transportgrenze: Ein erfolgreicher Sendeaufruf bedeutet zunächst nur, dass die Nachricht in den begrenzten lokalen Sendepuffer aufgenommen wurde. Wer wissen muss, ob eine Maschine oder Anwendung den Befehl tatsächlich ausgeführt hat, braucht eine Antwort auf Anwendungsebene. Für sichere Wiederholungen nach einer Unterbrechung benötigt die Anwendung zudem eigene Befehlskennungen und eine Behandlung bereits ausgeführter Befehle. Control verspricht keine einmalige Ausführung über Verbindungsabbrüche hinweg.
Beide Gegenstellen müssen Control vor dem Verbindungsaufbau auswählen. Eine versionierte Profilkennung wird beim Handshake geprüft; ein unpassender Peer erhält keine stillschweigende Control-Verbindung. In passenden Builds lässt sich AES-GCM für authentifizierte Nutzdaten ausdrücklich konfigurieren. Die taggebundene Control-Dokumentation beschreibt API, Größenlimits und Konfiguration.
Sensor: aktuelle Messwerte ohne Wiederholungswartezeit
Das Sensor-Profil richtet sich an unabhängige Positions-, Zustands- oder Telemetriewerte. Es verzichtet auf ARQ-Wiederholungen und die zeitgesteuerte Live-Auslieferung über TSBPD. Verlorene Messwerte werden daher nicht durch eine spätere erneute Übertragung aufgehalten.
Stattdessen nutzt das feste Profil Vorwärtsfehlerkorrektur: Zu jeweils vier Datenpaketen wird ein Paritätspaket erzeugt. Fehlt genau ein Datenpaket einer solchen Gruppe und sind die übrigen Pakete samt Parität verfügbar, kann der Empfänger es rekonstruieren. Bei mehreren Verlusten oder fehlender Parität können Messwerte ausfallen. Das Profil garantiert keine lückenlose Zustellung.
Jede Sensor-Nachricht muss einen vollständigen Messwert enthalten und in die konfigurierte Paketnutzlast passen; größere Nachrichten werden nicht automatisch fragmentiert. Nach einer FEC-Rekonstruktion kann die Empfangsreihenfolge von der Sendereihenfolge abweichen. Anwendungen, die stets den neuesten Zustand verwenden wollen, sollten deshalb Zeitstempel oder fortlaufende Messwertkennungen mitführen.
Auch Sensor muss auf beiden Seiten passend eingerichtet sein. Optionales GCM authentifiziert direkt empfangene und rekonstruierte Nutzdaten, bevor sie an die Anwendung gelangen. Die Sensor- und FEC-Dokumentation nennt die Paketgrenzen und Fehlerfälle.
Session-Authentifizierung v2: Schlüssel an die Sitzung binden
Die optionale Session-Authentifizierung ergänzt den Schlüsselaustausch um einen Nachweis, der frische Zufallswerte beider Gegenstellen, ihre Socket-Identitäten und ihre Rollen einbezieht. Aufgezeichnete Schlüsselnachrichten aus einer anderen Sitzung können dadurch keine Schlüssel in einer neuen geschützten Verbindung installieren. Richtungsgetrennte Zähler weisen veraltete Schlüsselkontrollnachrichten zurück, lassen aber identische Wiederholungen zur Erholung von Paketverlust zu.
Version 2 authentifiziert darüber hinaus Header und Inhalt von FEC-Paritätspaketen, bevor diese den Decoderzustand verändern. Die Schutzbereiche sind bewusst getrennt: GCM authentifiziert Nutzdaten; Session-Authentifizierung schützt den sitzungsgebundenen Schlüsselaustausch und die FEC-Parität. AES-CTR allein bietet weiterhin keine Integrität der Nutzdaten. Gewöhnliche ACK-, NAK- und Shutdown-Nachrichten sowie nicht alle Handshake-Felder sind durch diese Erweiterung geschützt.
Die Funktion ist standardmäßig ausgeschaltet. Caller und Listener müssen sie beide aktivieren, eine Passphrase konfigurieren und Verschlüsselung erzwingen. Ohne passende Unterstützung scheitert der Verbindungsaufbau statt unbemerkt auf ein schwächeres Profil zurückzufallen. Das aktivierte Profil ist nicht mit Haivision-Peers kompatibel und unterstützt kein Rendezvous. Die Dokumentation zur Session-Authentifizierung benennt auch weitere Grenzen, darunter fehlende Forward Secrecy und die Notwendigkeit eines unabhängigen kryptografischen Reviews.
Weitere Änderungen und Qualifikation
Version 0.2.8 prüft nicht darstellbare Puffergrößen, ungültige FEC-Eingaben sowie widersprüchliche Handshake- und Profilkombinationen früher. Budgets für kryptografische Arbeit beim Verbindungsaufbau und für die Bearbeitung umfangreicher NAK- oder aufgeschobener Verwerfungslisten begrenzen die Arbeit pro Laufzeitdurchlauf.
Gezielte Korrekturen betreffen außerdem die Diagnose gescheiterter asynchroner Verbindungen, ACK-Fortschritt in Backup-Gruppen, Callback-Abbau, Keepalives während Quellpausen und das Weiterlaufen nach kurzen Netzunterbrechungen. Für Live-Übertragung mit periodischen NAKs gilt weiterhin eine wichtige Grenze: Ein letztes verlorenes Paket oder eine verlorene Paketfolge vor einer Quellpause wird nicht in jedem Fall wiederhergestellt. Für vollständige endliche Übertragungen ist der File-Modus mit seiner Timeout-Recovery vorgesehen.
Die Qualifikation des veröffentlichten Tags umfasst die Release-CI und Integrationen, Paket-Consumer, Linux-Pakete und die Windows-SDK-Prüfung. Die beiden Windows-Installer wurden unabhängig neu gebaut, signiert und als signierte Dateien geprüft. Solche Prüfungen qualifizieren die beschriebenen Builds und Szenarien, nicht automatisch jede Zielhardware, WAN-Strecke oder Anwendung.
Robotweax SRT bleibt pre-1.0. Teams sollten die benötigten Profile, Peers, Verschlüsselungseinstellungen und Fehlerfälle in ihrer eigenen Umgebung prüfen. Direkte C++-Consumer aus dem Quellbaum müssen mit passenden Headern und Bibliotheken neu gebaut werden; die öffentliche C-ABI-Linie bleibt 0.2.
Robotweax SRT 0.2.8 herunterladen · Release Notes und bekannte Grenzen lesen