WebSocket, MQTT, Socket.IO, and IOSignal
These technologies are not interchangeable layers.
| Technology | Main role | Application/server responsibilities |
|---|---|---|
| WebSocket | Bidirectional client–server messages | Identity, routing, connection-state and reconnection policy |
| MQTT | Broker-based publish/subscribe with hierarchical topics | Broker authentication, authorization, TLS, and QoS settings |
| Socket.IO | Its own protocol with events, rooms, and reconnection | Room rules, application handlers, and permissions |
| IOSignal | Channel, CID, and HOME CHANNEL message routing | Addresses, authentication, quotas, and application conventions |
An MQTT client cannot connect directly to an IOSignal server. A plain WebSocket client is not a Socket.IO client. IOSignal tags are not an MQTT topic tree.
Browsers and devices
MQTT can run in browsers over WebSocket; brokers such as Mosquitto can expose a WebSocket listener. IOSignal uses WebSocket for browsers and CongSocket over TCP for Arduino, with the server relaying between transports.
Authentication and encryption
WebSocket can use TLS (wss://) and HTTP-based authentication. Its protocol handshake has a different purpose from user login. See RFC 6455 security considerations.
MQTT authentication, access control, and TLS depend on the broker and configuration; see Mosquitto configuration. See the Socket.IO introduction for its protocol model.
TLS resource use depends on board, implementation, and configuration; PSK modes do not always require certificate-based public-key authentication. For IOSignal's pre-shared-key approach, see boho and its limits.