MQTT or popularly known as mosquitto is a Publish-Subscribe network protocol used in IoT(Internet of Things). MQTT is known for being extremely lightweight to transport messages between remote devices with minimal network and code usage. The GENESIS development team at phAIdelta bring you this comprehensive blog post, that is going to look at what MQTT is and throw light on some of the ways in which MQTT is currently being used.

MQTT is based on the publish/subscribe model, which provides real-time and reliable messaging service for IoT devices, using only very little code and bandwidth. Suitable for devices with limited hardware resources and network environment with limited bandwidth. MQTT is widely used in IoT, mobile internet, IoV, electricity power and other industrial applications. MQTT is very light weight and can run over any network protocols that provide bi-directional connections and supports MQTT.

How does MQTT work?

Just like a normal radio or Television broadcaster, MQTT also works on Publish and Subscribe models. Where a client can publish a message over a topic which can be subscribed by one or multiple clients over the same topic. There is no direct connection between publisher and subscriber.

MQTT is required to use a central Broker:

Above is a basic MQTT Architecture represented with a conventional broadcasting system. Where Studio (representing mqtt publisher) would publish the recording to a broadcasting station (representing mqtt broker) on a particular channel and broadcasting station which would broadcast the recording. all Subscribers (representing mqtt subscriber) who are tuned to that particular channel would receive recording.

The MQTT also works in the same fashion where an MQTT publisher would publish a message to broker on a particular Topic and MQTT Subscriber which is Subscribed to Broker over this Topic will receive the message. Publisher and Subscriber are not interconnected to each other, both Subscriber and publisher are connected to an MQTT broker. MQTT Broker handels exchange of messages by filtering out all messages based on topics. Multiple Subscriber can subscribe to one Topic.

The MQTT broker handles authentication of Things on the network as well as managing connections, sessions, and subscriptions. Its main responsibility is to receive all published messages and then send them to subscribed clients. The MQTT broker also queues messages for subscribed clients, delivering them according to the agreed QoS level.

Entities: There are two Type of network entities in MQTT protocol, an MQTT broker and MQTT clients.

MQTT broker handles authentication of messages on the network as well as managing connections, sessions and subscriptions. MQTT broker is responsible to receive and publish messages and then send them to subscribed clients according to the agreed QoS level.

MQTT client can be any device that can run the MQTT library and connect to MQTT broker over a network. MQTT Client can either be a subscriber who would receive messages or a publisher who could publish messages. Clients could communicate with each other indirectly through topics managed by MQTT brokers.

Messages are organized based on topics. When a publisher client has a new item of data to publish it sends a message to its connected broker with that topic. Broker than Broadcast this message to all Subscriber clients who are connected to that topic. Publisher and Subscriber clients are independent to each other and do not need to have any information about each other.

The broker would not retain any message unless the Publisher client has designated the broker to retain the message, otherwise the message is discarded. The broker will be able to retain the message if the publisher has SET retained flag (-r) in the message published. When a subscriber subscribes to a topic with a retained message it receives the retained message of most current value instead of waiting for the next update from the publisher. The broker is able to retain only one message for a topic, hence subscribers will be able to receive only the last message that was published.

A minimal MQTT control message can be as little as two bytes of data. A control message can carry nearly 256 megabytes of data if needed. There are fourteen defined message types used to connect and disconnect a client from a broker, to publish data, to acknowledge receipt of data, and to supervise the connection between client and server.

MQTT sends connection credentials in plain text format and does not include any measures for security or authentication. The default unencrypted MQTT port is 1883 and encrypted port is 8883. Encryption can be done over the Transport layer to protect the transferred information to prevent interception and modification.

Quality of Service:

The Quality of Service (QoS) level is an agreement between the sender of a message and the receiver of a message that defines the guarantee of delivery for a specific message. There are 3 QoS levels in MQTT:

• 0: At most once
• 1: At least once
• 2: Exactly once.

When talking about QoS in MQTT, We need to consider two sides of message delivery:

1. Message delivery from the publishing client to the broker.
2. Message delivery from the broker to the subscribing client.

We will look at the two sides of the message delivery separately because there are subtle differences between the two. The client that publishes the message to the broker defines the QoS level of the message when it sends the message to the broker. The broker transmits this message to subscribing clients using the QoS level that each subscribing client defines during the subscription process. If the subscribing client defines a lower QoS than the publishing client, the broker transmits the message with the lower quality of service.

0 - at most once (“Fire and Forget”) The minimal QoS level is zero. There is no guarantee of delivery. The recipient does not acknowledge receipt of the message and the message is not stored and re-transmitted by the sender. QoS level 0 is often called “fire and forget” and provides the same guarantee as the underlying TCP protocol.

QoS 1 - at least once (“Deliver at least once”) QoS level 1 guarantees that a message is delivered at least one time to the receiver. The sender stores the message until it gets a PUBACK packet from the receiver that acknowledges receipt of the message. It is possible for a message to be sent or delivered multiple times.

The sender uses the packet identifier in each packet to match the PUBLISH packet to the corresponding PUBACK packet.

If the sender does not receive a PUBACK packet in a reasonable amount of time, the sender resends the PUBLISH packet. When a receiver gets a message with QoS 1, it can process it immediately. For example, if the receiver is a broker, the broker sends the message to all subscribing clients and then replies with a PUBACK packet.

If the publishing client sends the message again it sets a duplicate (DUP) flag. In QoS 1, this DUP flag is only used for internal purposes and is not processed by broker or client. The receiver of the message sends a PUBACK, regardless of the DUP flag.

QoS 2 - exactly once QoS 2 is the highest level of service in MQTT. This level guarantees that each message is received only once by the intended recipients. QoS 2 is the safest and slowest quality of service level. The guarantee is provided by at least two request/response flows (a four-part handshake) between the sender and the receiver. The sender and receiver use the packet identifier of the original PUBLISH message to coordinate delivery of the message.

When a receiver gets a QoS 2 PUBLISH packet from a sender, it processes the publish message accordingly and replies to the sender with a PUBREC packet that acknowledges the PUBLISH packet. If the sender does not get a PUBREC packet from the receiver, it sends the PUBLISH packet again with a duplicate (DUP) flag until it receives an acknowledgement.

Once the sender receives a PUBREC packet from the receiver, the sender can safely discard the initial PUBLISH packet. The sender stores the PUBREC packet from the receiver and responds with a PUBREL packet.

After the receiver gets the PUBREL packet, it can discard all stored states and answer with a PUBCOMP packet (the same is true when the sender receives the PUBCOMP). Until the receiver completes processing and sends the PUBCOMP packet back to the sender, the receiver stores a reference to the packet identifier of the original PUBLISH packet. This step is important to avoid processing the message a second time. After the sender receives the PUBCOMP packet, the packet identifier of the published message becomes available for reuse.

When the QoS 2 flow is complete, both parties are sure that the message is delivered and the sender has confirmation of the delivery. If a packet gets lost along the way, the sender is responsible to retransmit the message within a reasonable amount of time. This is equally true if the sender is an MQTT client or an MQTT broker. The recipient has the responsibility to respond to each command message accordingly.

Best Practice

Use QoS 0 when :

• You have a completely or mostly stable connection between sender and receiver.
• You don’t mind if a few messages are lost occasionally.
• You don’t need message queuing.

Use QoS 1 when :

• You need to get every message and your use case can handle duplicates.
• You can’t bear the overhead of QoS 2. QoS 1 delivers messages much faster than QoS 2.

Use QoS 2 when :

• It is critical to your application to receive all messages exactly once. This is often the case if a duplicate delivery can harm application users or subscribing clients. Be aware of the overhead and that the QoS 2 interaction takes more time to complete.

Applications of MQTT

Since MQTT is such a light-weight protocol (in terms of data size and processing power needed), it is used primarily in IoT applications. A small IoT device such as an ESP8266 microcontroller can be used as a tiny independent sensor device, monitoring the conditions of its surroundings. Various smart home devices make use of MQTT to interact with other devices on the network, such as a Smart Light bulb that can brighten lights when a daylight sensor detects sunset, or more commonly, a thermometer inside a thermostat controlling room heating and cooling.

Due to its subscription-based system, managing these devices also becomes easier with home automation software such as Home Assistant. This also makes device discovery easier and standardized.

Aside from home automation, MQTT found its use in data analytics due to it being easy to integrate in many sensor devices. Being able to collect huge amounts of data of environmental conditions in a cost effective manner brings new light into forecasting techniques. This also means we can store sensor data reliably, and manage all these devices easily from one control center.

Reference:

1. A Beginners Guide to MQTT
2. MQTT Essentials Part 6