Understanding convenient scenarios for the MQTT protocol

Imagine that we have dozens of different devices that must exchange data between them. These devices have to request data to other devices and the devices that receive the requests must respond with the demanded data. The devices that requested the data must process the data received from the devices that responded with the demanded data.

The devices are Internet of Things (IoT) boards that have dozens of sensors wired to them. We have the following IoT boards with different processing powers: Raspberry Pi 3, Raspberry Pi Model B, Intel Edison, and Intel Joule 570x. Each of these boards has to be able to send and receive data. In addition, we want many mobile devices to be able to send and receive data, some of them running iOS and others Android. We have to work with many programming languages.

We want to send and receive data in near real time through the Internet and we might face some network problems, that is, our wireless networks are somewhat unreliable and we have some high-latency environments. Some devices have low power, many of them are powered by batteries and their resources are scarce. In addition, we must be careful with the network bandwidth usage because some of the devices use metered connections.

Tip

A metered connection is a network connection in which we have a limited amount of data usage per month. If we go over this amount of data, we get billed extra charges.

We can use HTTP requests and build a publish-subscribe model to exchange data between different devices. However, there is a protocol that has been specifically designed to be lighter than the HTTP 1.1 protocol and work better when unreliable networks are involved and connectivity is intermittent. The MQ Telemetry Transport (MQTT) is better suited for this scenario in which many devices have to exchange data between themselves in near real time through the Internet and we need to consume the least possible network bandwidth.

The MQTT protocol is a Machine-to-Machine (M2M) and IoT connectivity protocol. MQTT is a lightweight messaging protocol that works with a broker-based publish-subscribe mechanism and runs on top of Transmission Control Protocol / Internet Protocol (TCP/IP).

The following diagram shows the MQTT protocol on top of the TCP/IP stack:

Note

The most popular versions of MQTT are 3.1 and 3.1.1. In this book, we will work with MQTT 3.1.1. Whenever we reference MQTT, we are talking about MQTT 3.1.1, that is, the newest version of the protocol. The MQTT 3.1.1 specification has been standardised by the OASIS consortium. In addition, MQTT 3.1.1 became an ISO standard (ISO/IEC 20922) in 2016.

MQTT is lighter than the HTTP 1.1 protocol, and therefore, it is a very interesting option whenever we have to send and receive data in near real time with a publish-subscribe model and we require the lowest possible footprint. MQTT is very popular in IoT, M2M, and embedded projects, but it is also gaining presence in web applications and mobile apps that require assured messaging and an efficient message distribution. As a summary, MQTT is suitable for the following application domains in which data exchange is required:

• Asset tracking and management
• Automotive telematics
• Chemical detection
• Environment and traffic monitoring
• Field force automation
• Fire and gas testing
• Home automation
• In-Vehicle Infotainment (IVI)
• Medical
• Messaging
• Point of Sale (POS) kiosks
• Railway
• Radio-Frequency Identification (RFID)
• Supervisory Control and Data Acquisition (SCADA)
• Slot machines

As a summary, MQTT was designed to be suitable to support the following typical challenges in IoT, M2M, embedded, and mobile applications:

• Be lightweight to make it possible to transmit high volumes of data without huge overheads
• Distribute minimal packets of data in huge volumes
• Support an event-oriented paradigm with asynchronous bidirectional low latency push delivery of messages
• Easily emit data from one client to many clients
• Make it possible to listen for events whenever they happen (event-oriented architecture)
• Support always-connected and sometimes-connected models
• Publish information over unreliable networks and provide reliable deliveries over fragile connections
• Work very well with battery-powered devices or require low power consumption
• Provide responsiveness to make it possible to achieve near real-time delivery of information
• Offer security and privacy for all the data
• Be able to provide the necessary scalability to distribute data to hundreds of thousands of clients