Aller au contenu
Restorm Documentation Restorm

Simuler WebSocket, Socket.IO et MQTT

Le type de requête WebSocket donne accès à trois serveurs, selon le protocole choisi.

Clic droit sur un dossier ▸ Ajouter ▸ Serveur WebSocket / Serveur Socket.IO / Serveur MQTT.

Un élément Serveur MQTT en écoute : le port du courtier, le sujet et la QoS, l'état « 0 client(s) connecté(s) » et le message MQTT broker listening on mqtt://localhost:1884

Serveur WebSocket

Section titled “Serveur WebSocket”

Accepte les connexions entrantes sur localhost:<port> et permet d’émettre des trames vers les clients connectés.

Serveur Socket.IO

Section titled “Serveur Socket.IO”

Même chose, mais avec la sémantique Socket.IO : les messages sont des événements nommés.

Courtier MQTT

Section titled “Courtier MQTT”

Le plus intéressant des trois : Restorm héberge un véritable courtier MQTT local.

  • Un courtier par port.
  • Accessible en TCP brut et via une passerelle MQTT-sur-WebSocket — vos clients navigateur peuvent donc s’y connecter directement.
  • Les publications et les abonnements fonctionnent normalement, y compris QoS et rétention.

Cela permet de développer et tester une chaîne IoT complète sans installer Mosquitto ni dépendre d’un courtier partagé.

Partage de port

Section titled “Partage de port”

Ces serveurs partagent leur socket avec les serveurs HTTP du même port : Restorm aiguille les requêtes ordinaires vers les routes HTTP et les demandes de bascule (upgrade) vers le serveur temps réel.

Un serveur HTTP de simulation et un serveur Socket.IO peuvent donc écouter ensemble sur :8080 — c’est souvent exactement la topologie d’une application web réelle.

Dans un scénario

Section titled “Dans un scénario”

Les actions Fermeture serveur WebSocket et Fermeture serveur Socket.IO referment un serveur ouvert par une action de connexion en mode serveur. Voir Serveurs hébergés.