Message Queuing Telemetry Transport is a publish/subscribe (pub/sub) lightweight messaging protocol with small code footprint for constrained IOT devices and low-bandwidth, high latency or unreliable networks for efficient M2M communication. MQTT runs on top of the TCP/IP networking stack.
MQTT allows clients to connect as a publisher, subscriber, or both. Client connects to a broker that handles message passing while ensuring correct message delivery to listeners. MQTT treats a topic as a file path, filters messages based on where you subscribe in the tree path. Different message types exist with Qos level that helps with the handshaking of that process. The pub/sub pattern is an alternative to the traditional client-server model. pub/sub decouples a client, who is sending a particular message (publisher) from another client(s) receiving the message (subscriber(s)). This means that the publisher and subscriber don’t know about the existence of one another. Third component called broker known by both the publisher and subscriber, filters all incoming messages and distributes them accordingly. Pub/Sub holds Space decoupling where Publisher/subscriber do not know each other; Time decoupling where Publisher/subscriber do not need to run at the same time and synchronization decoupling where Operations on both components are not halted during publishing or receiving.
It is definitely a challenge to scale pub/sub to millions of connections. This can be achieved using clustered broker nodes in order to distribute the load over more individual servers. Message Filtering is based on Subject or Content or Type. Broker stores messages for clients that are not online.
Every subscriber gets the message if they subscribed to the topic and Queues are named after been created explicitly. Then it is possible to publish or consume messages. In MQTT topics are extremely flexible and can be created on the fly. MQTT client is any device from a micro-controller up to a full fledged server, that has MQTT library running and is connecting to an MQTT broker over any kind of network. The client implementation of the MQTT protocol is very straightforward and are available for a huge variety of programming languages. MQTT broker can handle up to thousands of concurrently connected clients. The broker is primarily responsible for receiving all messages, filtering them, decide who is interested in it and then sending the message to all subscribed clients. It also holds the session of all persisted clients including subscriptions and missed messages. Another responsibility of the broker is the authentication and authorization of clients. The MQTT connection itself is always between one client and the broker, no client is connected to another client directly. The connection is initiated by a client sending a CONNECT message to the broker. The broker response with a CONNACK and a status code. Once the connection is initiated MQTT will keep it open as long as the client doesn’t send a disconnect command or it looses the connection. MQTT-SN (sensor network) is a variation of MQTT aimed at embedded devices on non-TCP/IP networks, such as Zigbee.
The Eclipse Paho is an open-source client implementation of MQTT and MQTT-SN messaging for IoT. On the other side, there exist some open-access servers for MQTT clients (Broker): 1) Eclipse provides a sandbox server that can be accessed using
iot.eclipse.org as a hostname and 1883 as the port number. 2) HiveMQ provides an online MQTT dashboard that can be accessed using broker.hivemq.com as hostname and 1883 as TCP port number.
Discover more about MQTT: