Zum Inhalt springen
Restorm Restorm-Dokumentation

WebSocket, Socket.IO und MQTT simulieren

Der Anfragetyp WebSocket gibt je nach gewähltem Protokoll Zugriff auf drei Server.

Rechtsklick auf einen Ordner ▸ Hinzufügen ▸ WebSocket-Server / Socket.IO-Server / MQTT-Server.

Ein lauschendes MQTT-Server-Element: der Port des Brokers, das Sujet und die QoS, der Status „0 client(s) connecté(s)“ und die Meldung MQTT broker listening on mqtt://localhost:1884

WebSocket-Server

Section titled “WebSocket-Server”

Nimmt eingehende Verbindungen auf localhost:<port> an und ermöglicht das Senden von Frames an verbundene Clients.

Socket.IO-Server

Section titled “Socket.IO-Server”

Dasselbe, jedoch mit der Socket.IO-Semantik: Die Nachrichten sind benannte Ereignisse.

MQTT-Broker

Section titled “MQTT-Broker”

Der interessanteste der drei: Restorm hostet einen echten lokalen MQTT-Broker.

  • Ein Broker pro Port.
  • Erreichbar sowohl über rohes TCP als auch über ein MQTT-über-WebSocket-Gateway – Ihre Browser-Clients können sich also direkt damit verbinden.
  • Veröffentlichungen und Abonnements funktionieren normal, einschließlich QoS und Retention.

Damit lässt sich eine vollständige IoT-Kette entwickeln und testen, ohne Mosquitto zu installieren oder von einem gemeinsam genutzten Broker abhängig zu sein.

Port-Sharing

Section titled “Port-Sharing”

Diese Server teilen sich ihren Socket mit den HTTP-Servern desselben Ports: Restorm leitet gewöhnliche Anfragen zu den HTTP-Routen und Umschaltanfragen (upgrade) zum Echtzeit-Server weiter.

Ein simulierter HTTP-Server und ein Socket.IO-Server können also gemeinsam auf :8080 lauschen – das ist oft genau die Topologie einer echten Webanwendung.

In einem Szenario

Section titled “In einem Szenario”

Die Aktionen WebSocket-Server schließen und Socket.IO-Server schließen schließen einen von einer Verbindungsaktion im Servermodus geöffneten Server. Siehe Gehostete Server.