Despite its name, MQTT (Message Queuing Telemetry Transport) does not provide message queuing in the traditional sense (like in systems such as RabbitMQ, IBM MQ, or ActiveMQ).
Here’s the clarification:
- The “MQ” in MQTT is a historical artifact from its origins at IBM in the late 1990s. It was inspired by IBM’s MQSeries (now IBM MQ), but MQTT itself is not a message queue system.
- MQTT provides publish-subscribe messaging, not queue-based messaging. There is:
- No built-in message persistence across subscribers (unless retained messages or persistent sessions are used).
- No message routing or load balancing like you’d find in real queuing systems.
- No message backlog per subscriber (unless configured with features like persistent sessions).
However, MQTT can simulate some queue-like behavior:
- Persistent sessions: Allow a subscriber to receive messages published while it was offline.
- QoS levels: Ensure messages are delivered reliably (to some extent).
- Retained messages: Let the broker store the last message on a topic and send it to new subscribers.
- Some MQTT brokers (e.g., EMQX, HiveMQ) offer extensions/plugins to integrate with real message queues or provide queue-like semantics.
Summary:
Feature | MQTT | Real Message Queue (e.g., RabbitMQ) |
---|---|---|
Pub/Sub model | ✅ Yes | ❌ Usually point-to-point |
Traditional queuing | ❌ No | ✅ Yes |
Message persistence | 🟡 Optional | ✅ Yes |
Load balancing | ❌ Not built-in | ✅ Yes |
So: MQTT does not inherently offer traditional message queuing, despite the name. It’s optimized for pub/sub communication, especially in IoT and constrained environments.
Reference: https://chatgpt.com/share/684d561a-f4b8-8002-a9b6-69a21beed17a
Specifications: https://mqtt.org/mqtt-specification/
Discover more from Habarisoft Blog
Subscribe to get the latest posts sent to your email.