There are many MQTT clients and servers in different languages and operating systems: it is an excellent solution for connected embedded systems. And of course, there are JavaScript clients for web applications. At Openest we had the chance to use on a real life project, here are our conclusions.
In our opinion, the main strengths of MQTT are:
- It is agnostic as to the information it allows to pass through, it is only a transport protocol for connected objects. The maximum payload size of a message is 256MB
- Its lightweight: only slightly increases bandwidth consumption
- It makes it easy to control the reliability of information transmission
- It is an abstraction for network management: for unstable connections, disconnection/reconnexion management is simplified
- It allows many customers to receive or distribute information
- Encryption via TLS/SSL
- The ability to manage which customers have the right to access or publish information
What is the operating principle?
MQTT allows customers to publish and/or subscribe to information. All clients communicate with a broker: a program in charge of receiving the published information and forwarding it to the subscriber clients:
Clients can publish or subscribe to MQTT topics, such as “/data/A”, which makes it easy to identify information. Customers can subscribe to several topics.
All the information flows through the broker. Communication between clients is never direct, which can be a disadvantage for some projects.
Why manage Quality of Service (QoS) when MQTT uses TCP?
For each topic, MQTT allows to manage the desired QoS, messages will be delivered:
- QoS 0 : Not more than once
- QoS 1: At least once
- QoS 2: Exactly once
TCP ensures the reliability of transmissions over the network. But MQTT also allows to manage connection losses, during a reconnection, in QoS 1 and QoS 2, the information not transmitted is retransmitted.
In QoS 1, messages are acknowledged by the receiver, if this acknowledgement does not arrive the message is forwarded:
In QoS 2, the acknowledgement itself is validated to ensure that the message only arrives once:
In QoS 0 on the other hand, the information is simply transmitted and validated only by TCP:
Using MQTT for a connected embedded systems on Linux
There are many MQTT clients and brokers. And making a choice is not easy. Wikipedia presents the features implemented by these software, it is a good starting point.
In our case, we were looking for a library that could be used in a C program embedded in Linux. As well as a broker running on an embedded device also running on Linux. The objective is to transmit information flows divided into packets of 1/10 of a second on about ten topics.
- The broker
The reference broker under Linux is called Mosquitto, developed under the Eclipse Public License 1.0 license by the Apache Foundation. It is available in Buildroot, so it was quite naturally that we evaluated and selected it. - The client
To link to a C program on Linux, we considered two candidates: Mosquitto’s C client library and libPaho in C. They are both maintained by the Apache Foundation and published under Eclipse Public License 1.0. After evaluating them, we opted for Paho.mqtt.c, for the clarity of its documentation and its integration with Buildroot (this is not the case with Mosquitto’s client library).
A great tool for connected embedded systems but be carefull
MQTT is an excellent solution for connected embedded systems and its adoption is expected to increase in the future. In the context of software written in C language, it greatly simplifies network management, especially connection/reconnexion cases.
Nevertheless, we should always use it with security in mind. MQTT main weakness is its main strength: allowing devices to communicate with each other. If an attacker can establish communication with a broker, it can access all data from all devices this can be catastrophic. So you need to design well secured embedded systems.
One Response