IoT Architecture and Communication Protocol

The system uses the MQTT (Message Queuing Telemetry Transport) protocol for bidirectional real-time communication with edge devices (displays). The server implementation is based on the mqtt.js library and wrapped in MqttService which manages connections, security, and pooling.

Topics

All communication occurs under topics in a fixed format, where :deviceId is the unique device identifier.

Topic	Publisher	Subscriber	Description	Payload
device/:id/command	Server	Device	Send commands to device	{ "type": "RELOAD", "commandId": "...",params": {} }
device/:id/response	Device	Server	Response to command	{ "commandId": "...", "success": true, "result": {} }
device/:id/status	Device	Server	Status report (Heartbeat)	{ "state": "online", "version": "1.0.0", "ip": "..." }
device/:id/telemetry	Device	Server	Performance data (CPU/RAM)	{ "cpu": 40, "memory": 512, "uptime": 3600 }

Server Architecture

1. Connection Pooling

When the system operates at high scale, a single server cannot efficiently maintain thousands of open MQTT connections. MqttConnectionPoolService manages a pool of connections (Clients) and uses them in rotation to send messages, instead of opening a new connection for each request.

2. Security and Encryption

When MQTT_USE_ADVANCED_SECURITY=true:

• The Payload is encrypted (End-to-End) using unique keys per device.
• MqttSecurityService verifies permissions (ACL) before sending/receiving from a specific Topic.

3. Reliability

• QoS 1: Messages are sent with acknowledgment (At least once).
• Retained Messages: Critical configuration messages are retained in the Broker so the device receives them immediately upon connection.
• Fallback: The system detects disconnections and keeps commands Pending until reconnection (or Timeout).

Docker Configuration

The Broker server is Eclipse Mosquitto, configured in docker-compose.yml.

• Internal port: 1883
• WebSockets port (for browser): 9001 (if in use)