MQTT: The Enabler of smooth and hassle-free information exchange for an IoT ecosystem

What is MQTT and what is it for?

MQTT is a widely used messaging standard making publisher to subscriber machine-to-machine communication possible. With MQTT at work, end-users devices and programs don’t communicate with the server straightforward. Instead, they have to subscribe for broker-published content assistance. 

Most communication is done taking the help of an IP. At times, different bi-directional means are called for assistance. As it’s an OASIS standard, OASIS MQTT Technical Committee is takes care of its specification management task. 

Owing to its unmatched flexibility and utility, it became the standard means of communication for the IoT-enabled devices. It has gained considerable fame as it can operate seamlessly even if there are restrictions on CPU and bandwidth for the system or network. 

As this protocol can deal with latency efficiently, MQTT is used widely in wireless network communication. It has a wide reach covering the healthcare, automotives, and other sectors that are using IoT applications. 

MQTT history

Andy Standford Clark and Arlen Nipper hold the credit to introduce the MQTT protocol to the world. The invention took place in 1999. The recorded first use of MQTT an oil pipeline monitoring solution built using SCADA. 

The firm needed something lightweight and power-efficient for this job as the control systems were linked using satellites. When its version 3.1 was released, IBM called it as MQ Telemetry Transport.

When IBM presented v3.1 in front of OASIS in 2013, then only MQTT became the standard name. Its version 3.1.1 came into existence in 2014. 

v5, came into being recently, in 2019. This recent version is laced with features like reason codes, message expiry, and subscription sharing. Though the MQTT rights are reserved to IBM, it’s now an open-source resource. 

Features of MQTT protocol

Out of existing messaging protocols, MQTT is considered the most suitable for IoT as it features certain traits, making it apt for IoT. These distinctive features are as under:

• Relaxed Getting Around 
  

MQTT is easy-to-use and can be deployed at service services. It offers endless pre-built brokers and clients applicable for immediate use. Such a professionally built messaging protocol cuts down the application development time significantly and makes this job achievable by rookie developers.

• Reliable Connectivity 
  

Connectivity, which occurred using the radio connection, isn’t always reliable. Sadly, the majority of IoT devices transmit data in a similar fashion only. 

MQTT cut down the connectivity issue by offering an in-built QoS feature that queues messages, saves them at MQTT broker, and makes them wait till the targeted device is all set to accept it. This reduces the odds of message misplacement, so the message is destined to reach the destination. 

• It encourages omni-directional messaging 
  

With MQTT, messaging is immeasurable as transmission can happen on any device and as much as conceivable. Any IoT solution can talk about a topic for indeterminable time duration. 

• Scale the message 
  

Developers can scale messages as per the need of the hour. Whether you need to broadcast a message on a million devices or a hundred devices, it’s easy to succeed in the task in every situation. 

How does MQTT work?

MQTT operations are exactly contrary to the customary client-server model, wherein the communication occurs directly. In the MQTT model, communication happens indirectly, via PUSH/SUBSCRIBE topology.

The client, such as MQTT Explorer, connects to related publisher, transmitting the message to it. This shared data, now, is decoupled from the sender, i.e. client, and passed to the next stage.

Broker in the process receives this decoupled piece of data and forwards it to subscribers.

As MQTT lets a good count of subscribers as well as publishers to join hands with brokers. This way, they can get messages related to interesting topics. 

If anyhow, there is a disturbance in broker-subscriber connection, the message will be saved at broker’s end and forwarded again when the connectivity restores. However, in the case of publishers, if broker’s connection is lost without intimation, it caches the message to related subscribers on its own.

Being event-driven, MQTT doesn’t support continual data transfer and keeps it under control. Data is only transmitted when actually needed.

MQTT broker

The functioning of MQTT is mainly based on MQTT broker, which is a premise for cloud-deployed computer-operated software. It could be operated by a third–party or self-operated. Its implementations could be proprietary or open-source. 

In general, it plays the role of a post office for MQTT as this protocol doesn’t take the help of the targeted recipient for delivering the message. In place of receivers’ addresses, it brings the topic into action. Intended users have to subscribe to that topic if a message copy is required. A single broker can get messages sent by assorted clients just as various publishers can post topics on a central subscriber. 

MQTT brokers are responsible for making application and device structure a bit more secure and decoupled. It’s because MQTT brings TLS encryption into action for usernames and connections. 

A broker is able to accumulate data as retained messages and keep a record of all the sessions. Its introduction in the system is useful as it’s easy to eradicate the presence of insecurities and vulnerabilities from client connections, makes message scale easier, and trims down the burden on the network.

The four stages of the MQTT session

Each MQTT session life cycle has four stages, explained briefly below:

• Connection
  

This stage is initiated when an MQTT client-broker establishes a TCP/IP connect. The task is accomplished using a standard or custom port, as explained by the operator. The key point to keep in mind at this session stage is ensuring no old session is running on TCP/IP. In that case, connection will be disturbed hugely. 

• Authentication
  

Before completing the connection, using the 1883 or 883 ports, the client verifies the server certificate’s authenticity and approves it. For this, the client provides SSL/TLS certificate details to the broker who verifies the server certificate details.

If SSL/TLS is not offered as a server certificate, the verification of users or authentication happens through user credentials that are sent as plain text. If open-source brokers are accepting anonymous clients then no inputs are offered in the username and password section. 

• Communication
  

Once the authentication completes, the MQTT session reaches the communication stage wherein the client is allowed to subscribe and ping, alongside publishing messages/operations. At this stage, the binary data block is shared by the publisher. The data block refers to the topic, explained by the publisher. MQTT can transmit message data up to 256 MB. 

• Termination
  

Lastly, termination happens when anyone, subscriber or publisher, wants to end the ongoing MQTT session. 

A DISCONNECT message is dispatched from the willing side and the receipt, i.e., broker processes the request. As the broker is informed of session termination, it’s known as a graceful shutdown. At times, termination is done abruptly, the broker sends the cached infromation to concerned subscriber(s).

MQTT QoS

The use of MQTT ensures quality in message delivery at each stage as it offers QoS features. With this feature, developers can guarantee quality communication. The various QoS stages or levels are as enlisted: 

1. ‍QoS -1 
   

The minus one stage of MQTT has ‘fire and forget’ as its synonym, because of its working and nature. This QoS level is apt in apps that do not prioritize destined message delivery. The broker will not bother if the message will reach its ideal destination. As no hard connection, for exact delivery, is made, power consumption is less. Mostly, it is used in non-critical applications. 

Key Features 

• Applicable to the devices where MQTT-SN is used 
• No need to have an MQTT connectivity 
• The sender of message cannot retire it 
• Becomes QoS 0 when message reaches the broker and is received by it.
  

Key Use Cases

• Use it for low-powered IoT application 
• When cutting down the messaging cost is the goal 
  

2. ‍QoS 0 
   

This QoS is for delivering the message to a particular destination for only once. On success, it directly stops. It operates only in the presence of an MQTT connection. That implies it’s not that energy-optimized.

Key Features 

• It puts best possible efforts in ensuring accurate delivery of message in question
• Don’t wait for response after delivering the message/information
• The sender can’t retire it 
• A broker won’t queue the message on disconnecting
• Less efficient from QoS-1 
  

Use Cases

• Suitable for power-constrained IoT application 

3. ‍QoS 1 
   

QoS 1 is the last QoS level and is used for the delivery of time-sensitive messages. It is accomplished by storing and queuing messages till the subscriber is fully ready to receive the message. 

Key Features

• Confirm the successful sending of the text/data at least once (by sending acknowledgement or something similar)
• The sender holds the message and proceeds further only when it addresses to take the PUBACK command from the addressee.
• Allows exchange and delivery of same message twice or more.

MQTT use cases 

The best use case for MQTT is the development of apps for remote monitoring. As it is lightweight, it can easily communicate with satellites. There, it is used for the purposes like alerting people about dangers, fire detectors, theft detection, or tracking a purpose within or outside a premise. 

Other than the above, the MQTT protocol is suitable for the development of text-based messaging apps, supporting real-time communication. 

Such an app can capitalize the energy and data efficiency features of MQTT to the maximum extent.

One of the real-world examples of the app, developed with MQTT, is Facebook Messenger. MQTT is the reason why it is lightweight, doesn’t consume too much phone battery, and delivers messages quickly. 

IoT applications, developed with M2M, are also ideal use cases of MQTT. Applications related to logistics, smart homes, real-time monitoring, and the healthcare industry can be built with MQTT.

Using MQTT in the IoT

IoT is where MQTT is consumed the most as it necessitates the least possible resources and is eligible to work seamlessly on microcontrollers. IoT devices operate on the internet and need constant connection with the network. As MQTT headers are minute, network bandwidth optimization is possible. 

It can be scaled as per the need of the hour. At a time, it can connect with a million devices without asking for any further resources. 

Below-mentioned are some of the key use cases of MQTT in IoT:

• As MQTT warrants for delivering the message. It supports exact and quick meter readings leading to precise billing in real-time. IoT applications for remote monitoring run on power-efficient sensors. As MQTT has low data broadcast requirements, it’s the best choice for IoT remote sensor applications.
• MQTT is used widely in applications that need healthy and ensured machine data delivery. For instance, Ably claims to develop a wind turbine, using MQTT, that shares accurate data on the turbine’s operation accuracy with the local team. This data is exchanged before the data reaches the data center.
• IoT devices that are involved in billing/invoices are able to reduce the possibilities of data duplication and misplacements as the broker ensures the message reaches its destination. 
• Regardless of the purpose, MQTT in IoT promotes continual information sharing, publishing, and information exchange in resource-limited IoT devices. 

Advantages and disadvantages of MQTT

Deploying MQTT protocol for IoT device communication reaps assorted benefits, such as:

• Smooth Communication 
  

Ensuring continual communication becomes simple as MQTT provides a unified communication connection for a specific topic. No matter from which source messages are coming from a particular topic, they all will be gathered in a central place. The complexity in message exchange owes greatly to the logically structured data. There is no confusion at data infrastructure and is designed to be flexible.

• Prevents the need for Polling
  

For adequate information exchange, message consumers are bound to poll each time new information is added to a message. It consumes time and double-up the burden on the network. The introduction of MQTT curbs the requirement of polling as it supports push-based delivery. Also, delivery is quick. Hence, the exchange happens quickly.

• Hassle-free Service Discovery
  

Service discovery is a seamless and error-free job with MQTT as a publisher will carry out the responsibility of message posting, related to a particular topic. This is not the case of other messaging standards as they first create a roster for messages to be transferred and they process the message. It’s time-consuming and has higher error possibilities.

• Message customization 
  

It is easier with MQTT as it allows developers to alter the communication patterns without producing ripple as the aftereffect of the changes.

Despite all these advantages, MQTT isn’t eligible to be called flawless as certain drawbacks exist:

• MQTT features a slow transmission cycle and makes the data transportation a bit elongated. With this, it creates a scalable network, for which, operating on a global level is a tough task. Maintaining authentication and interoperability at each broker demands hard work.
• It’s not a video-streaming supportive protocol. Though TLS encryption is offered, one has to build the security layer later on.
• MQTT is not planned with undivided attention to security. This is why its security is hardly impressive. It comes with limited authentication facilities, only for passwords and usernames, while sharing them as clean text. If one adds SSL/TLS to enhance its security then communication becomes overburdened.

‍

Is MQTT secure?

Generally, MQTT is a secure protocol. However, it can face dire security concerns if its implementation is not done properly. If any loophole is left here then the entire IoT application’s security will be compromised. A recent study by Avast revealed that more than 49,000 MQTT servers were accessible for everyone. Out of these, 32,000 MQTT servers weren’t password-protected, which was the worst case. Data saved on all these servers were at high-security risks.

It’s a well-known fact that security measures, implemented at the API level, bring the best protection. Hence, one must adopt viable security practices. However, it’s a tedious job as it takes millions of APIs for IoT application development. 

Wallarm is a great choice to make as this API security platform offers multi-layer API safety solutions, applicable in various cloud environments. It will help you keep OWASP 10 security risks at bay from MQTT messages and help you secure the final application. 

The platform adopts strong API testing practices and helps a developer to spot the API security vulnerabilities in their infancy stage and keep the damage as least as possible. 

As far as MQTT server security is concerned, access control, username, and password protection are enough for the task. Also, the server implementation should be done in the DMZ and the firewall should be placed in front of the server.
As MQTT operates on TCP/IP, MQTT security is only half-baked if these two resources are not protected. SSL/TLS implementation on TCP/IP can resolve the issue. But, it makes otherwise light communication a bit heavy.