MQTT – Publish/Subscribe and Message Queue
What is MQTT ?
MQTT used to stand for MQ Telemetry Transport, but is today referred to simply as MQTT and is no longer an acronym. It is an extremely simple and lightweight Publish/Subscribe messaging protocol invented at IBM and Arcom (now Eurotech) to connect restricted devices in low bandwidth, high-latency or unreliable networks.
If you’re new to messaging protocols visit this : MQTT | What is MQTT | MQTT in Depth | QoS | FAQs | MQTT Introduction
Recommended: MQTT Servers/Brokers | MQTT Public Brokers List
Publish/Subscribe is a messaging pattern that aims to decouple the sending (Publisher) and receiving (Subscriber) party. A real world example could be a sport mobile app that shows you up-to-date information of a particular football game you’re interested in. In this case you are the subscriber, as you express interest in this specific game. On the other side sits the publisher, which is an online reporter that feeds a system with the actual match data. This system, which is often referred as the message broker brings the two parties together by sending the new data to all interested subscribers.
The Publish/Subscribe messaging pattern brings many benefits:
- Implement the publisher and subscriber parties independently from each other
- Publishers and Subscribers don’t require to know each other
- One Subscriber could receive from many different Publishers
- One Publisher could send data to many different Subscribers
The benefits can be sumarized to Loose Coupling, the decoupling of publisher and subscriber, as well as Scalability through the parallel nature of the publisher and subscriber components.
Many standardized messaging protocols that implement a Publish/Subscribe pattern exist. In the area of application level protocols the most interesting ones are:
- AMQP, Advanced Message Queueing Protocol
- MQTT, MQ Telemetry Transport
- JMS, Java Messaging Service
- XMPP, Extensible Messaging and Presence Protocol
A publish/subscribe messaging protocol is only as useful as its message broker implementations.
A Message Queueing system receives, stores and forwards messages. Those actions tend to vary heavily from one implementation or messaging protocol to another.
The core component of a queueing system is, of course, a data structure called queue. The underlying theory of a queueing system is quite complex, so let’s assume for now that a queue is some sort of a database. While most general purpose databases have powerful query capabilities such as the SQL query language, a queue in it’s most basic form only knows two operations, push and pop.
The Push operation inserts a new element to the queue, the Pop operation reads the oldest element from the queue and deletes it afterwards. This is also called the FIFO model, first in first out. In certain cases the Pop operation should always read the newest element instead of the oldest. Such a datastructure is called a stack, while the model is called LIFO, last in first out.
A message queueing system could implement more advanced queuing operations like message priority support or ways to automatically delete old messages.
A message queue is a perfect addition to the Publish/Subscribe pattern because it backs the decoupling principle. For this reason most Publish/Subscribe protocol implementations rely on a message broker that also implements a message queuing system.