MQTT Brief Description

mqtt = Message Queuing Telemetry Transport

Description

MQTT is a lightweight publish/subscribe messaging protocol. It is designed for use with low power sensors, but is applicable to many scenarios.

This manual describes the features of MQTT version 3.1.1/3.1, to assist end users in getting the most out of the protocol.

Publish/Subscribe

The MQTT protocol is based on the principle of publishing messages and subscribing to topics, or "pub/sub".

Multiple clients connect to a broker and subscribe to topics that they are interested in.

Clients also connect to the broker and publish messages to topics.

Many clients may subscribe to the same topics and do with the information as they please.

The broker and MQTT act as a simple, common interface for everything to connect to. This means that if you have clients that dump subscribed messages to a database, to Twitter, Cosm or even a simple text file, then it becomes very simple to add new sensors or other data input to a database, Twitter or so on.

Connecting

The publisher and subscriber never touch each other. The connection is always established by the broker.

A MQTT broker always connects clients who want to share and clients who want to receive data.

Usually, the broker supports common security measurements, e.g. TLS.

Still, the end user has to make sure that the chosen measurements fit the security environment the broker itself is part of.

For example, a MQTT client is located after a router, using the NAT (Network Address Translation) to transmit from a private network address to a public address.

messages = any kind of data (text, pictures, .json, etc.)

MQTT is not a message queue - Attention!

It's possible to have message queues per client in MQTT.

Even though a few characteristics seem to be the same, particular the publish-subscribe model ("pub-sub").

In contrast, message queues store messages, as the name tells, and forward these messages between server applications.

The biggest difference certainly is that message queues often offer very large data storage volumes, enabling to safe all data coming in. But on the other hand, offering only a little access capacity.

Basic Features

Quality of Service

MQTT defines three levels of Quality of Service (QoS). The QoS defines the level of guarantee to ensure that a message is received.

Higher levels of QoS are more reliable, but involve higher latency and have higher bandwidth requirements.

Messages may be sent at any QoS level, and clients may attempt to subscribe to topics at any QoS level. This means that the client chooses the maximum QoS it will receive.

Retained Messages

Messages set as 'retained' means that the broker will keep the message even after sending it to all current subscribers.

If a new subscription is made that matches the topic of the retained message, then the message will be sent to the client.

This is useful as a "last known good" mechanism. If a topic is only updated infrequently, then without a retained message, a newly subscribed client may have to wait a long time to receive an update.

With a retained message, the client will receive an instant update.

Clean session / Durable connections

On connection, a client sets the "clean session" flag, which is sometimes also known as the "clean start" flag.

If clean session is set to false, then the connection is treated as durable. This means that when the client disconnects, any subscriptions it has will remain and any subsequent QoS 1 or 2 messages will be stored until it connects again in the future.

If clean session is true, then all subscriptions will be removed for the client when it disconnects.

Wills

When a client connects to a broker, it may inform the broker that it has a will.

This is a message that it wishes the broker to send when the client disconnects unexpectedly.