Robotweax SRT 0.3.0 ist veröffentlicht. Gegenüber 0.2.9 bietet die Version auf unterstützten Plattformen eine Wahl beim Krypto-Backend, mehr Informationen und Richtlinien für die Zulassung von Peers, bessere Einblicke in Verbindungsgruppen und Korrekturen für das Transportverhalten bei bestimmten Zeit- und Recovery-Abläufen.
Robotweax SRT ist eine unabhängige Implementierung von Secure Reliable Transport. 0.3.0 ist die Projektversion von Robotweax, keine neue SRT-Protokollversion: Die kompatible öffentliche SRT-API und srt_getversion() bleiben bei 1.5.7. Die Shared-Library-ABI wechselt allerdings von 0.2 auf 0.3. Anwendungen und Abhängigkeiten müssen neu gebaut werden.
Zweites Krypto-Backend, OpenSSL bleibt Standard
Unter Linux und macOS kann Version 0.3.0 Mbed TLS ab 3.6.7 in unterstützten 3.6.x-Konfigurationen als Alternative zu OpenSSL verwenden. Der Release umfasst statische und dynamische Bibliotheksnutzer sowie Interoperabilitätsprüfungen zwischen den Providern für AES-CTR und AES-GCM. OpenSSL bleibt das Standard-Backend; die Wahl von Mbed TLS ändert für sich genommen nicht das gewöhnliche kompatible Wire-Profil.
Für Windows gibt es getrennte SDK-Installer für OpenSSL und das experimentelle Microsoft-BCrypt-Backend. Die Wahl des Providers erfolgt bewusst; daraus folgt keine identische Qualifizierung jeder Backend- oder Build-Kombination.
Mehr Kontext bei der Zulassung von Peers
Anwendungen können jetzt begrenzt große Peer-Handshake-Metadaten während der Zulassung und nach dem Verbindungsaufbau auslesen. Ein Listener erhält so zusätzliche Informationen für seine Entscheidung. Diese Angaben macht der Peer selbst: Ein Implementierungslabel oder anderer gemeldeter Wert ist keine authentifizierte Identität und kein Nachweis darüber, wer sich verbindet.
Für Pfadkennungen und Standby-RTT stehen die Erweiterungsrichtlinien OFF, REQUIRED und—nur auf Listenern—IF_OFFERED bereit. Mit der letzten Variante kann ein Listener sowohl gewöhnliche Peers als auch solche mit angebotener Erweiterung bedienen. Anwendungen können ihre Zulassungsregeln damit explizit wählen, statt bei allen Peers dieselben optionalen Funktionen vorauszusetzen. Pfadkennungen werden dadurch nicht zum Authentifizierungsmechanismus; Standby-RTT ist kein Beleg für die Gesundheit des DATA-Pfads.
Verbindungsgruppen: weniger falsche Ablehnungen, klarere Zähler
Der Release korrigiert falsche Gruppen-Ablehnungen über gebündelte Listener hinweg. Ein neuer Versuch kann sich außerdem erholen, wenn ein früherer Verbindungsversuch eine unbestätigte Zuordnung zu einer Peer-Gruppe hinterlassen hat. Das sind gezielte Korrekturen beim Verbindungsaufbau, keine Zusage für identisches Verhalten jeder Gruppentopologie gegenüber der Referenzimplementierung.
Die Gruppenstatistik summiert nun wiederholt gesendete Pakete und Bytes über alle Mitglieder. Beiträge bleiben berücksichtigt, wenn ein Mitglied die Gruppe verlässt und seine letzten Sendevorgänge abgeschlossen werden. Damit sind die Gruppenzähler bei wechselnden Pfaden aussagekräftiger.
Korrekturen in File-, Control- und Laufzeitpfaden
File/Stream- und Control/Message-Verbindungen behalten nun die ausgehandelte Kennzeichnung für Wiederholungsübertragungen bei. Bei einem positiven SRTO_LOSSMAXTTL-Wert kann die adaptive Behandlung umsortierter Pakete aus deren tatsächlicher Ankunftsreihenfolge lernen und Verlustmeldungen wie vorgesehen aufschieben. Im File-Modus bleibt vor dem Eintreffen von Empfänger-Rateninformationen außerdem der anfängliche Fenster-/RTT-Fallback erhalten. So führen spärliche Bestätigungen nicht mehr zu einem unnötig langsamen Start.
Weitere Härtungen betreffen die aus Callbacks ausgelöste Bereinigung, die Ablehnung von Bestätigungen für noch nicht zur Übertragung übergebene DATA, Grenzen für Peer-Credit und Sensor-Gap-Ablauf sowie Race Conditions beim Listener-Setup und doppelte Zulassungen. Die Testwerkzeuge bereinigen zudem Nachkommen entfernter Interoperabilitätsprozesse sicherer und verbessern die Prüfung asynchroner Bereitschaft und installierter Dokumentation.
Experimentelle Funktionen bleiben optional
Zwei Ergänzungen sind zur Erprobung enthalten und standardmäßig deaktiviert:
- ACP1-Authentifizierung von Laufzeit-Steuerpaketen verwendet richtungsgebundene Schlüssel und eine begrenzte Replay-Erkennung für unterstützte gewöhnliche Verbindungen, Broadcast-/Backup-Gruppen, Rendezvous und Gruppen-Rendezvous. Sie erfordert einen Build-Schalter und die ausdrückliche Aktivierung an beiden Endpunkten. Eine unabhängige kryptografische Prüfung steht noch aus; ACP1 ist kein unterstütztes Sicherheitsprofil und kein gewöhnlicher Haivision-kompatibler Modus.
- Peer-Implementierungsidentität stellt optionale, begrenzte und vom Peer selbst gemeldete Labels bereit. Sie verändert weder die Aushandlung der Kompatibilitätsversion noch der Fähigkeiten. Ein Label ist keine authentifizierte Identität.
Upgrade und Bewertung von 0.3.0
Der Wechsel auf die ABI-Linie 0.3 erfordert einen Neubau von Anwendungen und Abhängigkeiten, auch bei direkter Nutzung interner C++-Header. Die kompatible SRT-API bleibt bei 1.5.7; OpenSSL/AES-CTR bleibt das kompatible Standardprofil. Der Release stellt getrennte Windows-SDK-Installer und Prüfsummen bereit.
Wie bisher sollte die Bibliothek mit den eigenen Gegenstellen, Netzwerkbedingungen und Betriebsanforderungen geprüft werden. Vergleichende Grenzwerte für CPU-, Speicher- und Durchsatzregressionen wurden für diesen Release nicht qualifiziert; aus den Änderungen folgt keine allgemeine Performance-Zusage. Auch ACP1 benötigt weiterhin eine unabhängige Prüfung, bevor man es als Sicherheitsprofil einsetzt.
Robotweax SRT 0.3.0 herunterladen · Release Notes lesen · Qualifizierungsbericht ansehen