Message Queue Telemetry Transport Protocol

In this article we will look at Message Queue Telemetry Transport protocol (MQTT), which is one of the widely used protocols in IoT.

 

Introduction

MQTT is a open protocol. It is used for asynchronous message queuing. MQTT is a machine to machine protocol. It has been widely used with embedded devices. MQTT is a very simple publish / subscribe protocol. It allows you to send messages on a topic (channels) passed through a centralized message broker.

 

The MQTT module of API will take care of the publish/ subscribe mechanism along with additional features like authentication, retaining messages and sending duplicate messages to unreachable clients.

 

 

MQTT Protocol

There are three parts of MQTT architecture:

• MQTT Broker – All messages passed from the client to the server should be sent via the broker

 

• MQTT Server – The API acts as an MQTT server. The MQTT server will be responsible for publishing the data to the clients.

 

• MQTT Client – Any third party client who wishes to subscribe to data published by API, is considered as an MQTT Client.

 

 

The MQTT Client and the MQTT Server need to connect to the Broker in order to publish or subscribe messages. API gathers the sensor data through the Monitoring module, and the MQTT module publishes the data to provide different channels. On the successful connection of external client to the MQTT module of the API, the client would receive sensor data on the subscribed channel. Main responsibilities of a Broker are:

• Receive all messages
• Filter messages
• Decide which are interested clients
• Publish messages to all the subscribed clients

 

All messages published are passed through the broker. The broker generates the Client ID and Message ID, maintains the message queue, and publishes the message.

 

MQTT Topics

A topic is a string (UTF-8). Using this string, Broker filters messages for all connected clients. One topic may consist of one or more topic levels. Forward slash(topic level separator) is used for separating each topic level. A MQTT topic looks as shown in the figure below.

 

 

When API starts, the Monitoring API will monitor the sensor data and publish it in a combination of topics. The third party client can subscribe to any of those topics, based on the requirement. The topics are framed in such a way that it provides options for the user to subscribe at level 1, level 2, level 3, level 4, or individual sensor level data. While subscribing to each level of sensor data, the client needs to specify the hierarchy of the IDs. For e.g. to subscribe to level 4 sensor data, the client needs to specify level 1 id/ level 2 id/ level 3 id/ level 4 id. The user can also specify the sensor id that they wish to subscribe to. In that case, they need to specify the whole hierarchy of the sensor, starting from project id and ending with sensor id.

 

MQTT Features

Topics

Topics are the main subject construct for MQTT. A topic is the pipe or channel that messages are sent down. When sending a message, you send it down a specific topic. Two key concepts to understand here are “topic names” and “topic filters”.

 

Publishing and Subscribing

Publishing and subscribing to topics provides the basic functionality of MQTT. Instead of sending messages directly to the consumers, the producer publishes messages to a specific topic directly to the broker. The consumers subscribe to either a specific topic or a group of topics, called filters, and the broker sends the consumers the messages. The broker acts as a middleman for all communication, and it understands (via rules set by the developer) who can publish and who can subscribe to various topics.

 

QoS Levels

When publishing and subscribing, the client must specify what level of delivery and cross-session guarantee the message has. This is called quality of service (QoS) and there are three levels: 0, 1, or 2.

 

QoS 0

• Messages are sent at most one time
• They are not guaranteed to be delivered
• They are also the fastest
• They can be used to send regular information, where if one or two messages are not received, it isn’t a problem
• A thermostat sending the current room reading is a good use: if one message among a series of messages sent every 30 seconds gets lost, it isn’t a problem

 

QoS 1

• Messages are sent at least once
• If the recipient doesn’t send an acknowledgment (or “ACK”) back within a certain amount of time, it is resent
• QoS 1 is more reliable but not as fast as QoS 0, and is ideal for command-and-control messages, like setting the temperature of the thermostat

 

QoS 2

• Messages are delivered to the device exactly once
• Use a QoS 2 message if you want to make sure that only one copy of the message will be delivered to the application
• A good example would be adding 1,000 coins to a game console

 

Sessions Management

Sessions are a significant part of the MQTT specification; they provide a mechanism to allow a device to connect, subscribe, disconnect, and still receive messages that are published when the device is offline. These sessions capabilities remove the burden of guaranteed message delivery—and of retransmits—from developers. When the device connects, it can specify whether it wants to reconnect; reconnecting to a session will then allow the device to get whatever messages it missed.

 

Retained Messages

MQTT also has a feature of Message Retention. It is done by setting TRUE to retain the flag. It then retains the last message & QoS for the topic. When a client subscribes to a topic, the broker matches the topic with a retained message. Clients will receive messages immediately if the topic and the retained message are matched. Brokers only store one retained message for each topic.

 

Last Will

MQTT uses the Last Will & Testament(LWT) mechanism to notify ungraceful disconnection of a client to other clients. In this mechanism, when a client is connecting to a broker, each client specifies its last will message which is a normal MQTT message with QoS, topic, retained flag & payload. This message is stored by the Broker until it detects that the client has disconnected ungracefully.

 

MQTT Wildcards

MQTT clients can subscribe to one or more topics. At a time, one can subscribe to a single topic only. So we can use the following two wildcards to create a topic which can subscribe to many topics to receive data/message.

 

Plus sign (+)

This is a single level wildcard. This is used to match specific topic level. We can use this wildcard when we want to subscribe at topic level. Suppose we want to subscribe for all Floor level ‘AL’(Ambient light) sensors, we can use Plus (+) sign level wild card instead of a specific zone level. We can use following topic:

 

 

Hash Sign (#)

This is a multi level wildcard. This wildcard can be used only at the end of a topic. All data/messages get subscribed which match to left-hand side of the ‘#’ wildcard. In case we want to receive all the messages related to all sensors for floor1 , we can use Hash sign (#) multi level wildcard after floor name & the slash( / ):

 

 

Differences between HTTP and MQTT are as given below: