Simulare WebSocket, Socket.IO e MQTT
Il tipo di richiesta WebSocket dà accesso a tre server, in base al protocollo scelto.
Clic destro su una cartella ▸ Aggiungi ▸ Server WebSocket / Server Socket.IO / Server MQTT.
Server WebSocket
Section titled “Server WebSocket”Accetta le connessioni in ingresso su localhost:<port> e permette di emettere
frame verso i client connessi.
Server Socket.IO
Section titled “Server Socket.IO”Lo stesso, ma con la semantica di Socket.IO: i messaggi sono eventi denominati.
Broker MQTT
Section titled “Broker MQTT”Il più interessante dei tre: Restorm ospita un vero broker MQTT locale.
- Un broker per porta.
- Raggiungibile in TCP grezzo e tramite un gateway MQTT-su-WebSocket — i client in esecuzione nel browser possono quindi connettersi direttamente.
- Pubblicazioni e sottoscrizioni funzionano normalmente, comprese QoS e ritenzione.
Questo permette di sviluppare e verificare un’intera catena IoT senza installare Mosquitto né dipendere da un broker condiviso.
Condivisione della porta
Section titled “Condivisione della porta”Questi server condividono il proprio socket con i
server HTTP della stessa porta: Restorm smista le
richieste ordinarie verso le rotte HTTP e le richieste di passaggio
(upgrade) verso il server in tempo reale.
Un server HTTP di simulazione e un server Socket.IO possono quindi ascoltare
insieme su :8080 — spesso è esattamente la topologia di un’applicazione
web reale.
In uno scenario
Section titled “In uno scenario”Le azioni Chiusura server WebSocket e Chiusura server Socket.IO richiudono un server aperto da un’azione di connessione in modalità server. Si veda Server ospitati.