In the IOT community it’s buzzing about MQTT, I want to know what this is and what al the fuzz is about.
What is MQTT?
MQTT is a lightweight publish/subscribe messaging protocol designed for M2M (machine to machine) telemetry in low bandwidth environments. It was designed by Andy Stanford-Clark (IBM) and Arlen Nipper in 1999 for connecting Oil Pipeline telemetry systems over satellite. Although it started live as a proprietary protocol it was released Royalty free in 2010 and became an OASIS standard in 2014. MQTT is fast becoming one of the main protocols for IOT (internet of things) deployments.
There are two versions of MQTT. The original MQTT which was designed in 1999 and has been in use for many years and designed for TCP/IP networks. Here is the actual Specification MQTT V3.1 of the MQTT packet structure.
MQTT-SN which was specified in around 2013, and designed to work over UDP,ZigBee and other transports.
MQTT-SN doesn’t currently appear to be very popular. and the specification hasn’t changed for several years but I expect that to change as IOT deployments starts.
MQTT Basics -How MQTT Works
MQTT uses a publish /subscribe model which requires the use of a central Broker.
Clients do not have addresses like in email systems, and messages are not sent to clients. Instead messages are published to broker on a topic. The job of an MQTT broker is to filter messages based on topic and then distribute them to subscribers. A client can receive these messages by subscribing to that topic on the same broker. In this model there is no direct connection between a publisher and subscriber.
The model is similar to broadcast radio and TV were a TV or radio station broadcasts on a channel and listeners/viewers tune in to that channel.
However unlike the broadcast TV/radio model in MQTT all clients can publish (broadcast) and subscribe (receive).
Topics – MQTT Addressing
These are like channels in the TV radio model. Topics are what connects the publisher and subscriber. In MQTT there is no formal structure and a publisher is free to choose it’s own topic names and structure. There are however naming rules.
There is no limit to the number of levels in a Topic Name or Topic Filter, other than that imposed by the overall length of a UTF-8 encoded string. The following ru les apply to Topic Names and Topic Filters: - All Topic Names and Topic Filters MUST beat least one character long, [MQTT -4. 7 .3-1] - Topic Names and Topic Filters are case sensitive - Topic Names and Topic Filters can include the space character - A leading or trailing '/' creates a distinct Topic Name or Topic Filter - A Topic Name or Topic Filter consisting only of the '/' character is valid - Topic Names and Topic Filters MUST NOT include the null character (Unicode U+OOOO [Unicode] [MQTT-4.7.3-2] - Topic Names and Topic Filters are UTF-8 encoded strings they MUST NOT encode to more than 65535 by)es [MQTT-4. 7.3-3). See Section 1.5.3 There is no limit to the number of levels in a Topic Name or Topic Filter, other than that imposed by the overall length of a UTF-8 encoded string.Taken from the Specification MQTT V3.1
Topic names look very similar to URLs.
Topics are created by the subscriber and publisher and are not pre-assigned by the broker.
As long as a topic name follows the naming standards it is accepted by the Broker. A Topic name is a UTF-8 string, and must comprise of at least one character. Topics can be created in a hierarchical manner (levels) using a forward slash as a delimiter. Simple topic examples are:
topic = bulb1, topic = bulb2, topic = bulb3 or topic =bulbs/ bulb1, topic =bulbs/ bulb2, topic =bulbs/ bulb3
What Happens to Published Messages?
When a client publishes a message on a topic then the broker will distribute that message to any connected clients that have subscribed to that topic. Once the message has been sent to those clients it is removed from the broker. If no clients have subscribed to the topic or they aren’t currently connected then the message is removed from the broker. In general the broker doesn’t store messages.
Note: Retained messages, persistent connections and QOS levels can result in messages being stored on the broker/server.
MQTT Broker Connections
MQTT uses TCP/IP to connect to the broker. TCP is a connection orientated protocol with error correction and guarantees that packers are received in order. However that doesn’t mean that messages can’t be lost.
MQTT QOS Levels
Networks are unreliable and MQTT lets you select from 3 QOS levels depending on your requirements. If your application can tolerate lost or missing messages then you can choose the lowest level QOS 0.
Otherwise you will need to use QOS level 1 (at least once) or QOS level 2 (At most once).
The higher the QOS level the more message overhead is involved.
Because MQTT clients don’t have addresses like email addresses, phone numbers etc. you don’t need to assign addresses to clients like you do with most messaging systems.
MQTT Brokers or Servers
There are many MQTT brokers available that you can use for testing and for real applications. There are free self hosted brokers , the most popular being Mosquitto and commercial ones like HiveMQ. Mosquitto is a free open source MQTT broker that runs on Windows and Linux. If you don’t want to install and manage your own broker you can use a cloud based broker from Cloud service providers like IBM, Microsoft (Azure) etc. Eclipse has a free public MQTT broker and COAP server that you can also use for testing. The address is iot.eclipse.org and the port is 1883 or 8883(SSL).
Note: The original term was broker but it has now been standardized as Server. You will see Both terms used.
MQTT supports various authentications and data security mechanisms. It is important to note that these security mechanisms are configured on the MQTT broker, and it is up to the client to comply with the mechanisms in place.
So now that i know wat MQTT is we can have a look if we can build something with it!