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:

FeatureMQTTReal 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.