Introduction to MQTT

Everybody

talks about the Internet of Things nowadays. Increasingly affordable micro controllers like Arduino and Raspberry Pi are enabling cheap devices that measure sensor data and send it over the internet. The goal of this post is to introduce the lightweight protocol MQTT and its capabilities to send data between devices and other systems and to demonstrate them by implementing two clients with Eclipse Paho.

The term Internet of Things was first used by Kevin Ashton in 2009 for interconnecting physical devices over the internet. The basic idea is very simple: Physical devices can exchange data between each other or being controlled by others. Examples of such devices would be a refrigerator, a car, a building or basically any other electronic device. One of the most common use cases is the collection, transmission, consolidation and displaying of sensor data. The results could be a web dashboard with the aggregated values or an alarm, when a threshold is exceeded.

The application scenarios are almost unlimited. Imagine your alarm clock would know that your train to work is 15 minutes late and adjust itself accordingly. Also your coffee maker is switched on automatically 15 minutes later to make you a hot cup of coffee before you leave for work. Sounds like the future ? All that is already possible today. Ericsson predicts that in 2020 50 billion devices are connected over the internet. The communication between the huge amount of devices is enabled by IPv6 and lightweight communication protocols like MQTT.

Definition :

MQTT (Message Queuing Telemetry Transport) is a lightweight messaging protocol that provides resource-constrained network clients with a simple way to distribute telemetry information. The protocol, which uses a publish/subscribe communication pattern, is used for machine-to-machine (M2M) communication and plays an important role in the Internet of Things (IoT).

History :

MQTT was developed by Andy Stanford-Clark (IBM) and Arlen Nipper (Eurotech; now Cirrus Link) in 1999 for the monitoring of an oil pipeline through the desert. The goals were to have a protocol, which is bandwidth-efficient and uses little battery power, because the devices were connected via satellite link and this was extremely expensive at that time.

The protocol uses a publish/subscribe architecture in contrast to HTTP with its request/response paradigm. Publish/Subscribe is event-driven and enables messages to be pushed to clients. The central communication point is the MQTT broker, it is in charge of dispatching all messages between the senders and the rightful receivers. Each client that publishes a message to the broker, includes a topic into the message. The topic is the routing information for the broker. Each client that wants to receive messages subscribes to a certain topic and the broker delivers all messages with the matching topic to the client. Therefore the clients don’t have to know each other, they only communicate over the topic. This architecture enables highly scalable solutions without dependencies between the data producers and the data consumers.

Real world
applications :

Facebook Messenger, Facebook has used aspects of MQTT in Facebook Messenger. However, it is unclear how much of MQTT is used or for what; Moreover it is to be noted that this is a phone application not a sensor application.

Why MQTT ?

1. It is a publish/subscribe protocol

2. It has Multiple Quality of Service levels (QOS)

3. It has at-least-once and exactly-once semantics

4. It has a low overhead (2 bytes at minimum)

5. It supports offline messaging

6. It retains messages, like a key/value store

Publish / Subscribe :

The publish / subscribe (often called pub-sub) pattern lies at the heart of MQTT. It’s based around a message broker, with other nodes arranged around the broker in a star topology. This is a very different model to the standard client/server approach, and at first it might seem a little strange, but the decoupling it provides is a huge advantage in many situations.

Clients can publish or subscribe to particular topics which are somewhat like message subjects. They are used by the broker to decide who will receive a message. Topics in MQTT have a particular syntax. They are arranged in a hierarchy using the slash character (/) as a separator, much like the path in a URL. So a temperature sensor in your kitchen might publish to a topic like ‘sensors/temperature/home/kitchen’.

Security
:

Security for MQTT (and IoT devices in general) is a fairly big topic, one which we’ll be writing about further in the future, but for now, there are two main security features, authentication and encryption.

Authentication is provided by sending a username and password with the MQTT connect packet. Almost all brokers and client implementations will support this however it is vulnerable to interception. To avoid this, TLS should be used if possible.

The protocol itself provides no encryption functionality but since MQTT runs on top of TCP, we can fairly easily use TLS and thus provide an encrypted connection. This does however increase the computational complexity of sending and receiving messages, which can be a problem on constrained systems and will also impact broker performance.

Broker Software :

There are a number of different broker implementations available. I’ll list the most popular systems here:

Mosquitto - One of the earliest production ready brokers, Mosquitto is written in C and offers high performance with a lot of configurability. Mosca - Written in Node.js, this can be embedded in a Node application or run as a standalone executable. This is our favourite broker due to its easy configuration and extensibility. Its also very performant. RSMB - IBM’s implementation of the MQTT protocol. This is one of the less popular options but is a mature system, written in C. HiveMQ - HiveMQ is a relatively new player, and is oriented towards enterprise environments. They have a lot of great information about MQTT on their blog.

MQTT is a fantastic protocol and its applications to IoT and M2M

communications are endless. If you’re looking for a very lightweight messaging system, it’s a great choice and is likely to become very popular over the next few years. Hopefully this article will be enough to get you up and running.