Basic Idea
MQTT (Message Queuing Telemetry Transport) is a lightweight publish-subscribe-based messaging protocol.
MQTT vs HTTP
The publish/subscribe architecture which is used in MQTT is in contrast to HTTP with its request/response paradigm.
The difference to HTTP is that a client doesn’t have to pull the information it needs, but the broker pushes the information to the client, in the case there is something new. Therefore each MQTT client has a permanently open TCP connection to the broker. If this connection is interrupted by any circumstances, the MQTT broker can buffer all messages and send them to the client when it is back online.
A Machine-to-machine (M2M) Protolcol
MQTT is a machine-to-machine (M2M) protolcol, which means that it is designed for resource constrained devices that have limited processing and storage capabilities, and that often run on batteries.
Based on TCP/IP
MQTT is based on TCP/IP.
While MQTT-SN is a variation of the main protocol aimed at embedded devices on non-TCP/IP networks, such as Zigbee and Bluetooth.
The difference to HTTP is that a client doesn’t have to pull the information it needs, but the broker pushes the information to the client, in the case there is something new. Therefore each MQTT client has a permanently open TCP connection to the broker. If this connection is interrupted by any circumstances, the MQTT broker can buffer all messages and send them to the client when it is back online.
Component
A MQTT-based scenario has three roles:
- Publisher: The role of the publisher is to connect to the message broker and publish content
- Subscriber: They connect to the same message broker and subscribe to content that they are interested in
- Message broker: This makes sure that the published content is relayed to interested subscribers
An MQTT system consists of mutiple clients that only communicate with a broker server and don’t know the existence of other clients. A client may be either a publisher of information or a subscriber
Content is identified by topic. When publishing content, the publisher can choose whether the content should be retained by the server or not.
- If retained, each subscriber will receive the message(s) precedingly published upon subscribing
- If not, the broker will discard the message directly.
Interaction
Since MQTT is a connection-based protocol, a client first sends a connect message to the broker with parameters required for client identification.
Afterwards, a client (subscriber) registers its interest on a specific topic by sending a subscribe message.
A client (publisher) publishes some content by sending a publish message to the broker which contains data published on a certain topic.
The broker forwards received publish message to all subscribers interested in the topic.
Each message is followed by an acknowledgment sent by a responder (i.e., suback and puback messages). Additionally, if a client wants to unsubscribe from a topic it can send an unsubscribe message and will receive an unsuback message as a reply.
To enable persistent communication, an MQTT broker needs to be aware of the connectivity state of the clients. Therefore, the MQTT protocol defines the pingreq and pingresp messages which are exchanged between a broker and client if no other messages have been sent within a certain time-frame.
Content
Topic
Topic Representation
A topic is a simple string that can have more hierarchy levels, which are separated by a slash.
A sample topic for sending temperature data of the living room could be house/living-room/temperature.
- The forward slash character (/) is used as a delimiter when describing a topic path
- Topics are case-sensitive
Wildcard in Topic
-
+: single-level wildcard character - only allows arbitrary values for one hierarchy -
#: multi-level wildcard character
When a client (subscriber) subscribs to a specific topic, it can usea wildcard, therefore subscribing to either a specific topic by providing its exact path, or a collection of topics using either the single-level + or multi-level # wildcard character.
For example, the subscription to house/+/temperature would result in the subscription of any topic sent to house/living-room/temperature as well as any topic with an arbitrary value in the place of living room, e.g., house/kitchen/temperature.
Quality of Service
There are three Quality of Service levels in MQTT available while publishing content, which is classified in increasing order of overhead:
- Unacknowledged service - at most once
- the message is sent only once whatever the message is actually delivered or not and the client as well as broker takes no additional steps to acknowledge delivery
- Acknowledged service - at least one
- The message is re-tried by the sender multiple times until acknowledgement is received (acknowledged delivery).
- Assured service - exactly onece
- Information is not only acknowledged but sent in two steps (i.e., two-level handshake). First it is transmitted and then delivered. Each step is acknowledged. This makes sure that the content is delivered exactly once to each subscriber.
Message types
-
Connect
-
Disconnect
-
Publish
Security
Since the MQTT protocol itself does not consider security, therefore, it does not define any security facility in the MQTT protocol itself.
For example, the support for user authentication in MQTT is weak. Plain text username and password authentication exists, but it provides an obvious risk if the server is not hosted in a controlled environment.
To circumvent the most obvious problems, MQTT can be used over an encrypted connection using SSL/TLS.
Alternative Protocols
Alternative protocols include the Advanced Message Queuing Protocol (AMQP), Streaming Text Oriented Messaging Protocol (STOMP), the IETF Constrained Application Protocol, XMPP, DDS, OPC UA, and Web Application Messaging Protocol (WAMP).
Reference
- Waher, P., 2015. Learning internet of things. Packt Publishing Ltd.
- MQTT 101 – How to Get Started with the lightweight IoT Protocol - https://www.hivemq.com/blog/how-to-get-started-with-mqtt