MQTT for dummies

In our projects, we are currently working on various communication protocols such as Http, MQTT or Coap. Especially in the area of IoT MQTT is a protocol that has established itself in recent years. Among other things, MQTT is used to connect IoT devices to backend platforms such as ThingWorx. Also in the area of Connected Car MQTT is also used. One example of this is the Joynr framework from BMW CarIT.

As we are confronted with MQTT in our daily business, we have created a summary with the most important points about the protocol, which we would like to present in this article.

The MQTT protocol follows the rules of a Publish-Subscribe communication. There are two different participants: a broker and "n" clients, whereby the clients do not communicate directly with each other as publishers and subscribers, but "publish" (publish) and "subscribe" (subscribe) to messages. The broker's task here is to manage and distribute messages.

Advantage of this communication paradigm: decoupling of publisher and subscriber (based on HiveMQ)

• Space decoupling: Publisher and subscriber do not need to know each other (IP address or similar)
• Time decoupling: Publisher and Subscriber do not have to be executed at the same time
• Synchronization decoupling: Operations on the executing computers do not block for the time of message transmission (asynchronous messaging)

The individual components of MQTT and their technical details are explained below.

MQTT Clients

The client is, as is typically imagined, the "end user" of the communication and the one who actively sends messages. A client can receive messages from a topic (subscriber) and publish messages in the same topic (publisher) at the same time. Each client identifies itself with a client ID, which also identifies its session completely, as MQTT is completely stateless for the client side.

MQTT Topics

MQTT communication is based on a so-called "topic" principle:

• Each message is assigned to a topic. This means that every valid MQTT message contains a payload with an associated topic.
• Topics are very similar to folders in a file system in terms of function and writing syntax. For example, a valid topic would be called "5OG/room5/temperature sensor/temperature".
• Topics must be subscribed to by the clients in order to receive messages. If a new client joins the network and sends the broker a subscription to the topic "5OG/room5/temperature sensor/temperature", the broker will forward all messages with this topic to the subscriber - but be careful - only to exactly this topic, and not to "5OG/room5/temperature sensor". It is also possible to "unsubscribe" from selected topics and no longer receive the corresponding messages.

There is also a mechanism with which the folder system of topics can be grouped: so-called single-level wildcards(+) and multi-level wildcards(#)

• The single-level wildcard replaces an element of a topic with a wildcard, i.e. a subscriber for the topic "5OG/+/temperature sensor/temperature" would receive all messages that correspond to the three specified levels, regardless of the wildcard. Messages for "5OG/room2/temperature sensor/temperature" or "5OG/hallway/temperature sensor/temperature", for example, would now be received.
• The multi-level wildcard replaces the entire following tree structure. A subscription to the topic "5OG/#" would receive absolutely all messages beginning with "5OG/", including e.g. "5OG/floor/table football/cheat module/status".
• Wildcards can be combined as required, for example "+/+/temperature sensor/#" for all temperature sensor data from all floors and rooms.

MQTT QoS

Messages are sent with a "Quality of Service" that offers three values:

• 0: "Fire-and-forget" - the package is sent exactly once. It arrives, or maybe not, just like the UDP protocol. Enormously fast.
• 1: "Acknowledgement" - the recipient confirms to the sender that they have received the parcel. It is possible for a parcel to arrive several times. Still fast.
• 2: "Synchronized" - the package is guaranteed to reach the destination, and only once, but this variant generates slightly more traffic.

MQTT Broker

The "backend" for MQTT, called Broker, manages and administers all data traffic. Its tasks include the storage, management and distribution of all information on topics, their subscribers, clients and their IDs, retained messages, etc. Despite the very narrow protocol, the bandwidth of the broker should be dimensioned accordingly for a very high number of clients. Nevertheless, the network utilization of MQTT communication is generally low.

The broker is the central mediation platform for MQTT message exchange. This means that if the broker fails, all communication breaks down as clients cannot communicate with each other. Fortunately, it is possible to "bridge" different brokers, i.e. to connect them with each other in order to create a redundant system if fail-safety is required. Most public broker implementations such as Mosquitto already have ready-made implementations for bridging. This bridging mechanism can also be used to build "broker networks" - which exchange configurable information and messages on various topics and pass them on to their corresponding clients.

Extras

All messages are generally received and distributed directly, with the exception of specially marked "Retained Messages". These are stored on the broker and linked to the topic. This message is automatically sent to each new subscriber to the topic once the connection has been successfully established. Only one retained message can be saved for each topic. Retained messages that have already been saved are overwritten by new ones. This enables, for example, the persistence and delayed receipt of messages, even if they are not sent regularly.

Last but not least, MQTT offers a kind of failover - the "Last-Will" - a configurable packet that is sent by the broker as soon as a client terminates a connection improperly, due to network errors or similar. For example, a will message can be sent to "5OG/room5/temperature sensor/status" with the payload "unreachable" or "0" - this notifies subscribers that the client is unexpectedly unreachable.

This results in nested communication with highly targeted data traffic, and the network code for clients is very lean and simple to implement.

Would you like to know how MQTT will have developed by 2024?