Simular WebSocket, Socket.IO e MQTT

O tipo de pedido WebSocket dá acesso a três servidores, conforme o protocolo escolhido.

Clique com o botão direito numa pasta ▸ Adicionar ▸ Servidor WebSocket / Servidor Socket.IO / Servidor MQTT.

Um elemento Servidor MQTT à escuta: a porta do broker, o tópico e a QoS, o estado “0 cliente(s) ligado(s)” e a mensagem MQTT broker listening on mqtt://localhost:1884

Servidor WebSocket

Aceita as ligações recebidas em localhost:<port> e permite emitir tramas para os clientes ligados.

Servidor Socket.IO

O mesmo, mas com a semântica do Socket.IO: as mensagens são eventos nomeados.

Broker MQTT

O mais interessante dos três: o Restorm aloja um verdadeiro broker MQTT local.

Um broker por porta.
Acessível em TCP em bruto e através de um gateway MQTT-sobre-WebSocket — os seus clientes de navegador podem, por isso, ligar-se diretamente.
As publicações e as subscrições funcionam normalmente, incluindo QoS e retenção.

Isto permite desenvolver e testar uma cadeia IoT completa sem instalar o Mosquitto nem depender de um broker partilhado.

Partilha de porta

Estes servidores partilham o seu socket com os servidores HTTP da mesma porta: o Restorm encaminha os pedidos comuns para as rotas HTTP e os pedidos de mudança de protocolo (upgrade) para o servidor em tempo real.

Um servidor HTTP de simulação e um servidor Socket.IO podem, assim, escutar em conjunto na porta :8080 — é frequentemente esta, exatamente, a topologia de uma aplicação web real.

Num cenário

As ações Fecho do servidor WebSocket e Fecho do servidor Socket.IO fecham um servidor aberto por uma ação de ligação em modo servidor. Consulte Servidores alojados.