MQTT is a lightweight protocol typically used with IoT devices that are designed to be power efficient and consume minimal bandwidth.
The MQTT protocol runs over TCP/IP and is based on a bi-directional publish-subscribe model with lossless communication.
MQTT is a hugely flexible protocol but there are only two basic entities, the MQTT client and the MQTT broker.
The MQTT client can be any endpoint that implements the MQTT protocol. In the case of IoT, the client is the connected device such as a sensor, monitor, or Arduino board but MQTT is not restricted to IoT, the client could also be a smartphone or laptop for example.
MQTT clients do not communicate directly with each other but all interactions are ‘brokered’ by a server component referred to as the MQTT Broker which sits in between clients and handles the routing of messages between them.
All communication in MQTT is grouped into ‘topics’. MQTT clients can publish messages to topics and subscribe to receive messages from others. A topic can be any string and is intended to group subjects of common interest, for example, sensor updates would be published to a topic, as would messages in a group chat, depending on the use case.
The broker is responsible for managing which clients are subscribed to which topics, receiving messages published on a particular topic, and sending that message to any client subscribed for updates. When the connection between a client and broker is lost, the broker is also responsible for caching the message and delivering it to the client when the connection is re-established.
The MQTT broker is fundamental to the MQTT protocol and can be considered the MQTT Server. As previously mentioned the broker sits between all clients and facilitates communication between them.
Many MQTT brokers exist, both open source and proprietary and one of the most important architectural decisions of any MQTT-based deployment is how to host the broker. Since MQTT is designed to run at a very large scale, any broker architecture will need to scale accordingly and most corporate deployments will rely on cloud-hosted, proprietary offerings so they do not have any infrastructure concerns, though self-hosted options are also available.
Sitting in between all communication, the broker can retain messages and keep a secure record of all sessions; clients are isolated from each other and so client insecurities and vulnerabilities can be sandboxed and, depending on your network topology, a broker can reduce the traffic on your network as a whole & allows for more efficient routing.
Any client that supports the MQTT protocol can subscribe and publish to topics but all communication goes through the broker, as shown below.
PubNub offers our own MQTT broker, the MQTT bridge to seamlessly integrate PubNub with your MQTT solution. More information can be found at the end of this article.
Whilst often considered an IoT solution, MQTT is just the protocol that underpins many well-known IoT products. There are many features of MQTT that make it particularly well suited to efficient communication between devices:
Easy to get up and running
MQTT has been around for a long time and there are a large number of solutions, both proprietary and open source, that are robust, reliable, and scalable. These pre-existing MQTT components can be used in all manner of projects, from large solutions to passion projects without modification and regardless of developer experience.
Reliability and configuration
MQTT has the concept of quality of service (QoS), discussed in detail later, which queues and caches messages on the MQTT broker, delivering them to the client when the connection is re-established. This works particularly well for partially connected devices or clients with intermittent connectivity such as IoT devices.
The client does not have to consider the solution architecture
With MQTT, you publish messages to a topic and receive messages when they are available. As a client, you do not have to worry about establishing or re-establishing a connection or whether your recipient(s) are listening for your messages, it “just works”.
Designed for scale
MQTT can cope with whatever scale your solution requires from startups to global companies. Most famously, Facebook Messenger uses MQTT for its communication.
MQTT relies on TCP/IP for connectivity so follows a similar lifecycle
Connection
The MQTT client initiates a connection to the MQTT broker. Typically this will be over the standard MQTT ports (1883/883 for secure and insecure connections respectively)
Authentication
The MQTT protocol does not have any authentication considerations beyond using TLS for the underlying TCP/IP connection, which is sufficient for the vast majority of use cases.
Publish / Subscribe
Once connected, clients can publish or subscribe to topics to send and receive messages.
Disconnect
Disconnection can be initiated by either the client or broker and will cause the MQTT session to end after any in-progress requests have been processed.
Quality of Service allows a solution designer to specify how reliable an MQTT connection should be, in general, the more reliable the connection, the greater the potential memory overhead for retries and message retention.
QoS -1
The message is sent only once and the client and broker take no additional steps to acknowledge delivery. This is also known as “fire and forget”.
This only applies to messages sent by a client. Once messages are received at the broker, they are considered QoS 0
QoS 0
The sender and receiver engage in a handshake to ensure only one copy of the message is received. This assures delivery and avoids multiple copies of the message being sent.
QoS 1
The message is re-sent multiple times until its receipt is acknowledged by the recipient. This works best for time-sensitive messages but can lead to duplicate messages being received.
MQTT is a lightweight and power-efficient protocol that over the years has been used in the kind of solutions where those are key considerations.
IoT is the most popular example where MQTT is a great fit. IoT devices are typically battery-powered and can be very expensive to maintain, so lasting a long time between battery swaps is preferred. Whilst in the home environment it is not difficult to replace a battery now and then, in an industrial environment, with thousands of sensors, spread across a wide area and often in very difficult-to-reach locations their maintenance can get costly very quickly.
IoT use cases include fire detectors, theft tracking, location monitoring, sensors, engine status, etc. MQTT also has very low data overheads so, in those environments where data is expensive, or where thousands of devices are deployed so bandwidth is a concern, MQTT is ideal.
PubNub and MQTT work great together for IoT. Please see our IoT demo and IoT tutorial to learn more about how PubNub and MQTT can deliver a reliable, scalable, and efficient IoT solution.
MQTT is also very popular in real-time communication, the best-known example being Facebook Messenger. Why would Facebook choose to use MQTT? Because it would not drain your phone’s battery, would not use excessive data, runs on secure protocols, allows scaling, easily facilitates group chats, and distributes all data through a central MQTT broker backbone infrastructure.
Absolutely! PubNub provides an MQTT bridge offering very low latency which avoids having to deploy a custom MQTT broker and provides simple integration with other PubNub functionality such as functions and data streaming.
Since PubNub is designed around the publish-subscribe model, it maps very nicely to MQTT:
Publish / Subscribe: These concepts are identical for both PubNub and MQTT
PubNub channels: The equivalent in MQTT is the ‘topic’.
UUID: Both PubNub and MQTT have the concept of a unique identifier assigned to each client.
Wildcards: Both PubNub and MQTT support wildcards when subscribing to channels/topics. See the PubNub docs for more detail.
