Symulowanie WebSocket, Socket.IO i MQTT

Typ żądania WebSocket daje dostęp do trzech serwerów, w zależności od wybranego protokołu.

Kliknięcie prawym przyciskiem na folderze ▸ Dodaj ▸ Serwer WebSocket / Serwer Socket.IO / Serwer MQTT.

Element Serwer MQTT w trakcie nasłuchiwania: port brokera, temat i QoS, stan „0 podłączonych klientów” oraz komunikat MQTT broker listening on mqtt://localhost:1884

Serwer WebSocket

Przyjmuje przychodzące połączenia na localhost:<port> i pozwala wysyłać ramki do podłączonych klientów.

Serwer Socket.IO

To samo, ale z semantyką Socket.IO: wiadomości są nazwanymi zdarzeniami.

Broker MQTT

Najciekawszy z trzech: Restorm hostuje prawdziwy lokalny broker MQTT.

Jeden broker na port.
Dostępny przez surowe TCP oraz przez bramkę MQTT-over-WebSocket — klienty przeglądarkowe mogą więc łączyć się bezpośrednio.
Publikowanie i subskrypcje działają normalnie, wraz z QoS i retencją.

Pozwala to rozwijać i testować kompletny łańcuch IoT bez instalowania Mosquitto i bez zależności od współdzielonego brokera.

Współdzielenie portu

Te serwery współdzielą swoje gniazdo z serwerami HTTP na tym samym porcie: Restorm kieruje zwykłe żądania do tras HTTP, a żądania przełączenia protokołu (upgrade) do serwera czasu rzeczywistego.

Serwer symulacji HTTP oraz serwer Socket.IO mogą zatem nasłuchiwać razem na :8080 — często jest to dokładnie topologia rzeczywistej aplikacji internetowej.

W scenariuszu

Akcje Zamknięcie serwera WebSocket oraz Zamknięcie serwera Socket.IO zamykają serwer otwarty przez akcję połączenia w trybie serwera. Zob. Serwery hostowane.