OSS als Basis von SignalRC

SignalRC stützt sich auf eine Reihe quelloffener Bausteine, die sich wie Zahnräder in einem Getriebe drehen. In diesem Artikel sehen wir uns näher an, warum genau diese Werkzeuge gewählt wurden, wie sie zusammenspielen und welchen Beitrag sie für unseren ferngesteuerten DDC-Truck leisten, den wir im Artikel „SignalRC – in Echtzeit ans Steuer“ [1] ausführlich vorgestellt haben. Dabei geht es nicht nur um eine Feature-Liste, sondern auch darum, wie die einzelnen Projekte intern genutzt werden und welche Rolle sie innerhalb von SignalRC übernehmen.

SignalR – Echtzeitkanal für Steuerung und Telemetrie

Das Offensichtlichste zuerst: SignalR ist das Rückgrat der gesamten Kommunikation zwischen Server, Browser und Fahrzeug. Unter der Haube kapselt es verschiedene Transportprotokolle wie WebSockets oder Server-Sent Events und wechselt dynamisch zum besten verfügbaren Kanal. Auf Serverseite registrieren wir mehrere Hubs, die über AddSignalR eingebunden werden. Jeder Hub kapselt die Funktionen in eigene Blöcke. Der CarControlHub verwaltet zum Beispiel die Verbindung zu jedem Fahrzeug, vermittelt Authentifizierungsanfragen und leitet Steuerbefehle weiter. Sobald ein Fahrer über den Browser einen Kanal aktualisieren möchte, ruft er eine Hub-Methode auf, die den Auftrag samt Session-ID, Channel-Nummer und Zielwert an das entsprechende Fahrzeug weitergibt. SignalR sorgt nicht nur für die Pipeline, sondern liefert auch die Logik für Wiederverbindung und Nachrichtenreihenfolge gleich mit, sodass die Steuerung verlässlich und in Echtzeit arbeitet.

TypedSignalR – starke Typen für weniger Fehler

Damit die vielen Hub-Aufrufe nicht in beliebigen string-Methodennamen enden, setzt SignalRC zusätzlich auf TypedSignalR-Clients. Das Paket TypedSignalR.Client generiert zur Laufzeit Proxy-Interfaces, die exakt den Signaturen der Hub-Interfaces auf der Serverseite entsprechen. Auf dem Fahrzeug bedeutet das, dass ServerConnectionService ein stark typisiertes Proxyobjekt ICarConnectionServer erhält. Jeder Methodenaufruf wird somit zur normalen C#-Methode mit IntelliSense, statischer Typprüfung und klaren Rückgabewerten. Falsche Methodennamen oder veränderte Parameter fallen sofort beim Kompilieren auf.

MessagePack – kompakte Pakete für längere Fahrten

SignalRC verwendet MessagePack in unserem Projekt als Transportformat für alle Hubs, die mit dem Onboard-Client verbunden sind. Statt JSON-Strings reisen dadurch binäre Daten durch das Netz, die deutlich kleiner ausfallen. Auf Serverseite genügt ein AddMessagePackProtocol in der Hub-Konfiguration, um das Protokoll für den Onboard-Client zu aktivieren. Die getypte Anbindung passt perfekt dazu, weil MessagePack seine Schema-Informationen aus den C#-Typen ableitet und so ohne zusätzliche Mapper oder Reflection auskommt. Ergebnis: Weniger Bandbreite ohne extra Aufwand. 

MediaMTX – Streaming-Zentrale auf dem Fahrzeug

MediaMTX läuft direkt auf dem Raspberry Pi und dient als Video-Schaltzentrale. Die Onboard-Software startet das Binary als eigenständigen Prozess und übergibt ihm eine vorbereitete Konfiguration mediamtx.yml. Diese wird vom Onboard-Client zukünftig auch selbst geschrieben. Sie beschreibt, wie die Raspberry-Pi-Kamerastreams aufgenommen und zur Verfügung gestellt werden. MediaMTX integriert sich eng mit der Pi-Kamera über den Eintrag source: rpiCamera, übernimmt Bildparameter wie Auflösung, Bitrate oder Overlay-Text und startet über runOnInit einen ffmpeg-Befehl. Der Trick: ffmpeg nimmt den lokalen RTSP-Stream entgegen und schiebt ihn als RTP-Strom an den Janus-Server. MediaMTX überwacht außerdem den ffmpeg-Prozess und startet ihn automatisch neu, falls das Encoding einmal aussetzt. Dadurch muss der Onboard-Code keine eigene Prozessüberwachung implementieren und kann sich auf die hohe Verfügbarkeit des Video-Streams verlassen. Zusätzlich ließen sich hier Aufzeichnungen aktivieren oder alternative Eingangsquellen wie RTSP-Kameras zuschalten, ohne dass der Steuerungs-Stack davon etwas mitbekommt. All das erreichen wir über die Konfiguration in MediaMTX.

Janus Gateway – WebRTC-Brücke zwischen Pi und Browser

Janus ist der dedizierte WebRTC-Server der Plattform und läuft serverseitig. Das Projekt bringt alle Bausteine mit, um RTP-Streams aus dem Fahrzeug in WebRTC-Sitzungen für Browser-Clients zu verwandeln. Der SignalRC-Server startet Janus beim Hochfahren (sofern in den Einstellungen nicht deaktiviert) über den VideoStreamReceiverService. Dieser Service legt per HTTP-API dynamisch Streaming-Handles an, reserviert UDP-Ports in einem konfigurierten Bereich und weist jedem Fahrzeug seinen eigenen RTP-Eingang zu. Wenn ein Browser später den Stream abruft, verbindet er sich über das Janus-JavaScript-SDK, handelt ICE/RTP-Parameter aus und landet bei genau dem Stream, den Janus zuvor vom Fahrzeug über den Port erhalten hat. Janus selbst kümmert sich um Paketverlust, NAT-Traversal und Mediensignalisierung, während SignalRC nur die notwendigen Metadaten verwaltet. Dieser Aufbau entkoppelt die Fahrzeugseite von der WebRTC-Welt und erlaubt uns, mehrere Autos parallel zu betreiben, indem Janus jeweils eigene Sitzungen aufspannt. Das Beste: Wir kümmern uns nicht um die Details des Video-Streamings an sich, denn das ist ein komplett eigenes Rabbit Hole.

Next.js und React – Schaltzentrale im Browser

Die Weboberfläche ist als Next.js-Anwendung gebaut, die React-Komponenten mit Server-Rendering kombiniert. Next.js liefert uns Routing, API-Routen und optimiertes Bundling „out of the box“. Es kann als Development- oder als Production- Server gestartet werden – beides integriert. In Komponenten wie car-control oder telemetry importieren wir das NPM-Paket @microsoft/signalr und erstellen clientseitige Hub-Verbindungen. Dort werden Gamepads gebunden, indem wir sie aus dem Browser auslesen. Wir können React-Funktionen rendern, die nahtlos zwischen SSR und CSR wechseln – auch wenn der meiste Code tatsächlich auf dem Client läuft.

Zustand – State Manager im Client

Zustand verwaltet den zentralen UI-State. Der Store in control-flow-store hält Verbindungsdaten, Gamepad-Eingaben und Sessions. Komponenten abonnieren nur diejenigen Ausschnitte, die sie benötigen, und Re-Renderings bleiben minimal. Dadurch erreichen Eingaben den SignalR-Client ohne spürbare Verzögerung, und auch im Maschinenraum werden durch die minimalen Re-Renderings die Datenflüsse quasi unverzögert angezeigt.

React Flow – Steuerlogik als Baukasten

React Flow liefert die Grundlage für den visuellen Flow-Editor. Die Bibliothek rendert Nodes und Verbindungen direkt im Browser und erlaubt die Drag-and-Drop-Konstruktion wie in einem Baukasten. Jede Node steht für einen Steuerbaustein, jede Verbindung repräsentiert den Datenfluss zwischen Funktionen oder Kanälen. Anwender stellen damit komplette Steuerketten zusammen, speichern sie und übertragen sie an das Fahrzeug, ohne Code anzupassen. Das macht es jedem möglich, sein Fahrzeug so individuell zu gestalten wie gewünscht.

Zusammenspiel

Setzen wir die Bausteine zusammen: Der Browser lädt die Next.js-Anwendung, stellt über SignalR eine Verbindung zum CarControlHub her und authentifiziert sich mit einem per SSH-Schlüssel signierten Challenge-Response. Der Server lässt das Fahrzeug die Sitzung validieren, leitet Befehle an das Fahrzeug weiter und sorgt dafür, dass Janus den passenden UDP-Port für den Video-Stream reserviert. Auf dem Raspberry Pi empfängt ServerConnectionService die Steuerkommandos, führt sie im ControlExecutionService aus und hält die MediaMTX-Pipeline aktiv, die kontinuierlich das Kamerabild codiert. Janus transformiert den RTP-Datenstrom in WebRTC, und das React-Frontend zeigt das Ergebnis an, während Telemetriedaten parallel über weitere Hubs reisen. Jede OSS-Komponente übernimmt damit einen klar umrissenen Aufgabenbereich.

Warum Open Source großartig ist

Freie Software bietet weitaus mehr als nur die damit verbundene Kostenersparnis. Die Community liefert fortlaufend Patches, die Sicherheit, Performance und neue Hardwareprofile abdecken. Wir können Quellcode bis in die kleinsten Details prüfen, anpassen und bei Bedarf eigene Erweiterungen zurückspielen. Für die meisten Probleme gibt es schon eine Lösung. Das gilt besonders bei Komponenten wie Janus oder MediaMTX, die sich intensiv mit Videobearbeitung auseinandersetzen. Ich hätte gar nicht die Zeit gefunden, mein Projekt zu bauen, wenn der Video-Teil nicht schon zu großen Teilen fertig zu bekommen gewesen wäre. Warum also das Rad neu erfinden?

Sogar die Entwicklungsmaschine umgebaut

Meine aktuelle Entwicklungsmaschine ist ebenfalls auf Linux umgestellt, um noch einmal zu unterstreichen, wie großartig OSS ist. Bei Interesse gerne auch dazu mehr. 

Was nicht so großartig ist

Man muss bei aller positiver Grundeinstellung auch darauf achten, wie sich Lizenzen über die Zeit entwickeln. An verschiedenen Projekten haben wir in der Vergangenheit gesehen, dass sich deren Lizenz von einer auf die andere Version änderte. Böse Falle!

Fazit und Appell

Open-Source-Software kann heutzutage schon so viele Probleme lösen. Ich finde es ganz hervorragend, was manche Entwickler an Tools zur Verfügung stellen. Damit diese Entwickler nicht auf so gemeinschädliche Ideen kommen müssen wie Lizenzänderungen oder Ähnliches: Show some Love! Wer Geld mit quelloffener Software verdient, mag auch gerne etwas zu deren Entwicklung beitragen.

In diesem Sinne wünsche ich weiterhin viel Spaß mit meinem OSS-Projekt SignalRC. Über Sternebewertungen, Wünsche und Feedback freue ich mich natürlich.

[1] Georg Poweleit, SignalRC – in Echtzeit ans Steuer, dotnetpro 10-11/2025, Seite 46 ff.