Message Queuing Telemetry Transport /MQTT Basic

“MQTT is a Client Server publish/subscribe messaging transport protocol. It is light weight, open, simple, and designed so as to be easy to implement. These characteristics make it ideal for use in many situations, including constrained environments such as for communication in Machine to Machine (M2M) and Internet of Things (IoT) contexts where a small code footprint is required and/or network bandwidth is at a premium.“

Citation from the official MQTT 3.1.1 specification

MQTT have following characteristics:

Lightweight and efficient
Bi-directional communications
support for unreliable networks
Good scalability
Reliable message delivery

The latest version is MQTT 5, while most of the deployment is MQTT 3.x.

MQTT Architecture

Publish / Subscribe Pattern (pub / sub)

MQTT running on TCP and the way it works is little bit different compare to other TCP connection. Not like other TCP connection where the client send request the server and server responded then client display the response. in other word we can say it is alternative to traditional client server architecture.

The pub/sub model decouples the client that sends a message (the publisher) from the client or client that receive the message (subscriber).

Publisher and Subscriber never have direct contact. Both Publisher and Subscriber dont know if they exist.

The connection between Publisher and Subscriber is managed by Broker. The broker is responsible to filter all incoming messages and distribute to subscriber.

What is filtering capability of The Broker?

Subject based filtering
Content based filtering
Type based filtering

Topics/Subscription

Messages in MQTT are published on topics. There is no need to configure a topic, publishing on it is enough. Topics are treated as a hierarchy, using a slash (/) as a separator. This allows sensible arrangement of common themes to be created, much in the same way as a filesystem.

For example, multiple computers may all publish their hard drive temperature information on the following topic, with their own computer and hard drive name being replaced as appropriate:

sensors/COMPUTER_NAME/temperature/HARDDRIVE_NAME

Clients can receive messages by creating subscriptions. A subscription may be to an explicit topic, in which case only messages to that topic will be received, or it may include wildcards. Two wildcards are available, + or #.

+ can be used as a wildcard for a single level of hierarchy. It could be used with the topic above to get information on all computers and hard drives as follows:

sensors/+/temperature/+

# can be used as a wildcard for all remaining levels of hierarchy. This means that it must be the final character in a subscription. With a topic of “a/b/c/d”, the following example subscriptions will match:

a/b/c/d
#
a/#

Quality of Service (QoS)

MQTT defines three levels of Quality of Service (QoS). The QoS defines how hard the broker/client will try to ensure that a message is received. 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.

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

0: The broker/client will deliver the message once, with no confirmation.
1: The broker/client will deliver the message at least once, with confirmation required.
2: The broker/client will deliver the message exactly once by using a four step handshake.

Retained Message

All messages may be set to be retained. This 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.

Let's talk more detail about MQTT Client and MQTT Broker

MQTT Client

What is Client in MQTT Architecture? It is both Publisher and Subscriber.

MQTT client can be any device, ranging from IoT sensors, up to the server that run MQTT client and connect to MQTT Broker over network.

MQTT Broker

The server side of MQTT Architecture is the MQTT Broker. The Broker is the heart MQTT protocol.

Here’s the role Broker:

Receiving all messages
Filtering the messages
Determine who who subscribe to each messages
Send the message to respective subscriber
Hold session data of al clients that have persistent connection
Client Authentication
Client Authorization

iolib.link