Written by Andy Stanford-Clark (co-inventor of MQTT). Edited by Lucy Rogers
Note: This article was written in 2017, and refers to v3.1.1, which is the version which is most widely implemented, but v5 is the current version.
MQTT is a messaging system for the Internet of Things. (An introduction to the Internet of Things is available here). It makes it easy to get your Things connected using a widely used, standardised protocol.
This article explains the important parts, what it is, how to use it and why it was developed. The article on MQTT-Fu develops the information here further and describes use patterns that experienced MQTT application developers often adopt. It brings together some best practices that are often found in code, passed on verbally, or held in the minds of experienced MQTT practitioners.
But first ... what is MQTT?
MQTT is used to send messages from sensors and devices to applications on other computers and in the cloud. It is also used to send commands from an application to a device to tell it to do something. MQTT runs over network connections, wired and wireless, on a Local Area Network (LAN) and across the Internet.
MQTT looks after getting your message from A to B - you don’t need to know how. You just decide “what will I send?” and “what will I do with it when it gets to the other end?”.
This article explains the important parts of MQTT - publishers, which send messages, subscribers, which receive messages, and the “broker”, which sits in the middle and passes messages between them. The “topic” is a label that travels with the message, saying what the message is about, and the “payload” is the message. The topic is rather like the address on the outside of an envelope, while the letter inside is the payload. This article also explains how a broker decides which subscribers to send a message to, and how subscribers “ask” for that message. Other features, such as “Last Will and Testament”, “Quality of Service”, “Retained messages” and “Client ID” are also explained.
This article also takes you through a “hello world” Node-RED MQTT example, explains some aspects of security for MQTT brokers and gives the history of MQTT.
By the end of the article you should know enough about MQTT to use it for many applications. The article MQTT-Fu gives some extra hints, tips and ideas that you may want to use on more advanced projects.
Node-RED MQTT Hello World worked example
If you have not yet used Node-RED, there are some great introduction tutorials (e.g. https://magpi.raspberrypi.org/articles/cheerlights-orb-a-node-red-tutorial) and - try those to help this make sense.
In the Node-RED palette there are two types of node which handle MQTT communications: an input node and an output node. The output node is a publisher, and the input node is a subscriber. To configure these nodes, in their simplest form, you only need to know the IP address of an MQTT broker, and the topic you want to use.
Let’s write a “Hello World” application using MQTT in Node-RED. We will build a Node-RED flow which publishes a Hello World message to an MQTT broker, and which subscribes to the broker so that it receives and displays the published message.
Drag an inject node from the palette into your Node-RED flow. Add an MQTT output node (the one with a pip on the left side), and wire them together. Open the inject node by double-clicking it and select “string” from the Payload type pull-down menu. Type “Hello World” (without the quotes) into the Payload box. Click “Done” to close the inject node. Open the MQTT output node and next to Server click the pencil next to Add new mqtt-broker... In the Connection tab, next to Server, enter the IP address or name of an MQTT broker. If you don’t have one handy, you can use
on the default port of 1883. Pick a topic to use - if you’re using a public MQTT broker, pick something that will be unique to you - maybe your initials. Click “Done” to close the MQTT output node.
That’s our publisher done. Now for the subscriber that will receive our message.
Drag an MQTT input node (the one with the pip on the right-hand side) into your flow. Add a debug node and wire them together. Open the MQTT input node. Node-RED will already be showing the broker you set up for the output node. Set the topic for the subscription to be the same as the one you configured for the publisher. Close the MQTT input node. That’s the subscriber part of the application done.
Deploy your flow. Click on the Debug tab on the right-hand side. Click the inject node. The inject node sends your Hello World message to the MQTT output node.
The MQTT output node publishes the message to the MQTT broker on the topic you chose. The broker looks to see if there are any subscribers to that topic. It finds the subscriber you set up in your second flow and sends the message to it. The MQTT input node receives the message and passes it on to the debug node. The debug node displays the message in the debug tab.
Let’s look in more detail at publish-and-subscribe messaging, and some features of MQTT.
The Publish-and-Subscribe (pub/sub) model is based on the intuitive model of a magazine: every month a writer publishes an issue of a magazine, and sends it to a facility for printing and distribution. People who want to receive each month’s issue of that magazine subscribe to the magazine title. The Distribution facility, or “broker”, as it known in the pub/sub world, sends a copy of the magazine when it published to each person on the list of subscribers to that magazine.
And so it is with the pub/sub messaging pattern: a producer of messages sends (publishes) them to a central broker. Subscribers interested in receiving the messages connect to the broker and send a message, known as a subscription, to the broker telling it which publications they would like to receive. When a message arrives from a publisher, the broker makes a copy of the message for each subscriber and sends it directly to them. Thus each subscriber receives a copy of every publication in which they are interested.
The equivalent of the magazine title, is the “topic” in pub/sub messaging. Each message has a topic, which is rather like the subject line of an email address: it tells you what the attached message is about. So for example, if I publish a message “15.4”, it is meaningless without its associated topic “temperature”. Even then, you don’t know what it is that has temperature 15.4 - my house, car, greenhouse? Topics are generally richer than just “temperature”, and employ a hierarchical structure which puts the message into context - for example
“andy/car/temperature”. Someone wishing to find out how hot my car is could connect to the broker to which I am publishing my car’s temperature and subscribe to the “andy/car/temperature” topic.
The key thing about this messaging pattern is that publishers and subscribers are unaware of each other. Each client, whether publisher, subscriber or both, only communicates with the central broker. Subscribers don’t care which actual publisher sends a message, as long as it’s on the topic they are interested in. Moreover, publishers don’t need to know or care who will be receiving the messages they publish. There could be 1, 2 or 1000 subscribers to their publications, but all they have to do is send a single message to the central broker, and that’s their work done. This is particularly convenient for small devices with low processing and memory capabilities, and limited network bandwidth.
Protocols and Transports
We use the term “protocol” to mean the language that a device uses to send and receive messages from somewhere else across a network. The protocol specifies the exact sequence of bytes that are assembled to make a message, that is sent from or received by a device or other computer system. This usually includes the initial connection and introductory messages, the messages used to send and receive data, including any hand-shake messages that are sent back to confirm receipt, and the disconnection messages used at the end of a conversation. The term “transport” is often used in the same context. There is a subtle difference in the meaning of these terms, as they are used in this book. A transport specifies how a message is sent, but makes no statement about what is sent. A protocol specifies both: how a message is sent, and also the format of the content of the message. For example, a protocol might specify that a temperature (say) is to be represented as a two byte integer in big-endian format, describing a temperature to the nearest degree, in degrees Centigrade.
A transport can be thought of as like the postal service - you decide what you will send, package it up, and let the postal service deliver it for you. They don’t care what’s in your parcel, and you don’t care exactly how they deliver it (plane then train then van). You just decide what you will send, and what will you do with it when it gets to the other end. The postal service takes care of the job of actually delivering it for you.
MQTT protocol features
Now we will take a quick look at some useful features of the MQTT protocol:
- Subscriptions, including wildcards.
- Last Will and Testament, which gives you control over what happens if your client gets unexpectedly disconnected from the network.
- Quality of Service, which governs how hard clients and the broker will try to deliver a message successfully in the face of network failures.
- Retained Topics, which give you the latest value of a topic when you first subscribe to it.
There is more information about these, and other, features of MQTT in the article MQTT Fu.
Note that throughout this article we will be using version 3.1.1 of MQTT. At the time of writing, this is the current version of the MQTT standard (ISO/IEC 20922), and is the version that is by far the most widely implemented.
When an MQTT application wants to receive messages from a broker, it sends a subscription message to the broker to tell it what topics it is interested in. The broker stores the subscription, and any time a message arrives from a publisher, the broker looks at the topic and does a match against all the current subscriptions. It then sends a copy of the message to each of the subscribers that are interested in that topic.
When you use an MQTT input node in Node-RED you enter the topic that you’d like to receive from the broker, and when you deploy your flow, the Node-RED server connects to the broker and sends a subscription message for that topic. When a publisher sends a message to the broker on the topic you are interested in, the broker sends a copy of the message to your Node-RED server and it appears on the output pin of the MQTT input node.
MQTT does have an “unsubscribe” feature, which allows an application to dynamically modify its subscription during its execution. Node-RED does not currently have a way to dynamically subscribe and unsubscribe from topics during the execution of a flow. You have to specify the topic you are interested during the development of your application flow, and the subscription remains in place as long as the flow is running in the Node-RED server.
If the connection to the broker drops, Node-RED will automatically reconnect and re-subscribe for you.
Previously, we talked about subscribing to the ‘andy/car/temperature’ topic to get the temperature published by Andy’s car. Suppose we wanted to subscribe to other data that we know the car is publishing?
MQTT supports a mechanism to allow you to subscribe to a whole set of topics in one go. This is referred to as a “wildcard” subscription. There are two magic characters that we use in wildcard subscriptions: ‘+’ and ‘#’.
‘+’ goes into one or more of the sections of the topic delimited by ‘/’. It means “give me anything at all that appears here”. For our car example, if I wanted everything published from my car, and assuming the car followed the topic structure “andy/car/temperature”, “andy/car/speed”, etc, I would subscribe to “andy/car/+” to get everything.
If I wanted temperatures published by all my things, including car, house, greenhouse, etc, I would subscribe to ‘andy/+/temperature’.
You can put more than one ‘+’ in a subscription topic, so if I wanted any temperature from anyone, including andy, lucy, fred in the first section and car, house, greenhouse etc in the second section, I would subscribe to ‘+/+/temperature’.
The ‘#’ wildcard character enables you to subscribe to “everything below here” in the topic. Assuming a tree-like topic structure going from left to right, as we are familiar with in URL notation, then if I wanted to subscribe to everything pub- lished by andy, I would subscribe to “andy/#”. The main advantage of using the # character is that you don’t need to know in advance the exact topic structure that is being published. If some topics were of the form ‘andy/car/temperature’, and some were of the form ‘andy/weatherstation/indoor/temperature’, the # wildcard would catch all of them, not matter how many sections the topics have.
Using ‘+’ is more precise - if you only wanted the three-level topics (like ‘andy/car/temperature’) then use ‘+’ to precisely specify the topic pattern you want. If you just want “everything below here” then ‘#’ gives you that.
Note that if you want to receive all the messages published to the broker by everyone, you can just subscribe to ‘#’. The security settings on your broker may be set to prevent this, and if you run an internet-facing MQTT broker you are strongly advised to ensure that an anonymous client can not connect and subscribe to ‘#’ in order to snoop all the messages passing through your broker. Unfortunately, many of the well-known MQTT brokers are have their security features turned off by default, to make them easy to set up and play with. But responsible administrators must take care to ensure appropriate security is enabled in their production broker systems.
Last Will and Testament
When I (Andy) developed MQTT, I was thinking of future uses for it, and was considering its use for a highly scalable Instant Messaging system. One of the weaknesses of many of the Instant Messaging systems in use at the time, was that if you turned off your computer, it became ambiguous for a period of time whether you were still online or not. The little green indicator next to your name didn’t turn off reliably when you went offline suddenly. If you shutdown the Instant Messaging application cleanly, it would say “goodbye” and explicitly sent out a message to all interested parties to say you were going away.
I reasoned that some kind of “heartbeat” would be required to enable the broker to know that a client was still connected. But what to do if it wasn’t? It should send out a message to say “this client unexpectedly disconnected”. Sending the message “in band”, that is through the pub/sub messaging system seemed an elegant solution, as it could be treated in the same way, by subscribing clients, as if the client had sent out the “I’m going offline” message just before it disconnected. So it became thought of as “the message you would have published if you had known you were about to go offline”. But as it was an unexpected disconnection, you couldn’t have known that.
So I pictured a model similar to the lodging of a “Last Will and Testament” with a legal agent, to be executed (read) in the event of your death: when you connect to a broker, you can optionally lodge a “will” message (with its associated topic) with the broker. At that time you also declare a heartbeat interval that you intend to honour (say, 30 seconds). If you fail to send something (either a published message, or, if there’s nothing to send, just an “I’m alive” message called a “ping”), then the broker assumes you were unexpectedly disconnected. It closes the network connection (TCP/IP socket) to you, and publishes your Last Will and Testament message on your behalf, to any interested subscribers.
This mechanism provides a particularly elegant way of implementing an online status display. Coupled with a “birth certificate” which a client publishes when it comes online, the negation of that status by the Last Will and Testament message means the current status of a client can be accurately determined at any time.
There is an in-depth discussion of Birth and Death certificates in the MQTT Fu article.
Quality of Service
Some data is inherently more valuable, in some sense, than other data. For example, the wind speed data from my home weather station, published every 10 seconds, is not very valuable: if you miss the occasional one, it doesn’t really matter. There’s plenty more where that came from, and the next update is coming along very soon.
If you want to send me an electronic funds transfer over MQTT, on the other hand, we both care quite a lot that I receive the message. We also care quite a lot that I receive it only once. If you sent it once, but I received two copies of it for some reason, then I might think you were being very generous and have paid me twice. So once-and-once-only delivery can often be important. We are both happy to do some extra work to make sure that message is delivered reliably and just once.
In between those two extremes is the situation where you want to be sure the recipient receives the message, and it doesn’t matter if under certain situations (like a blip in the network connection) it gets there more than once. As long as it gets there at least once.
MQTT supports all three of these modes of delivery, and they are called the Quality of Service. The publisher of a message sets the quality of service on each message when it is sent. Quality of Service (QoS) 0, known as “at most once” delivery, is a simple single transmission of the message. As long as the network and the intermediate broker is connected and working, then the message should be delivered to any subscribers to that topic. But it might not. If any network connections break, or something happens to the broker, then messages can be lost. And that’s fine, because you chose QoS0, so have declared that you’re OK with that.
QoS 1 is “at least once” delivery. The parties involved in the transfer of the message - the publishing client, the broker and the subscribers each acknowledge receipt of the message. If the acknowledgement doesn’t get to the sender, after some period of time they will send the original message again, and will continue to do so until they receive an acknowledgement. Of course, during this procedure the original message may have been correctly delivered to the recipient one or more times, and just the acknowledgement gets lost, hence “at least once” delivery.
The highest quality of service, Qos 2, known as “exactly once” delivery, uses 4 messages between each sender and recipient (publisher to broker, broker to subscriber) to ensure that the message not only gets there, but also that it doesn’t get delivered more than once.
This is how it works, for a message being sent at QoS 2 from a publisher to its broker: the publisher sends the message to the broker and the broker acknowledges it with a “publish received” message. Until the publisher receives this acknowledgment it continues retrying the publish until it does. At this point the broker has not done anything else with the message - it just stores it. Then, when the publisher knows the broker has received the message, it sends a “publish release” message, to tell the broker to process the message: to match against the subscriptions it is holding, to work out which subscribers to send it to, and start the delivery process. The broker deletes the message from its store, and sends a “publish complete” message back to the publisher. If for some reason the publisher doesn’t receive that confirmation, it sends the Publish Release message again, until it does. However, because the broker knows it has already released that message (and has deleted it from its store), it just sends back another Publish Complete message to the publisher. At some point the publisher will receive one of these confirmations and the QoS 2 message transfer is complete.
In practice, QoS 2 is only rarely used by developers of MQTT applications. The vast majority of MQTT messaging happens at QoS 0. This is for a combination of two reasons: firstly that network connections are quite reliable, and most of the time it all just works. The second reason is a bit more subtle, and that is that publishers often need to know that the message has arrived at its destination (the subscriber). So you send at QoS 0 and the subscriber publishes a message back to a topic the publisher is subscribed-to saying “I got it”. That end-to-end confirmation is done at the application level, not at the MQTT level, so the sending application knows that the message has been received and acted on. If the message doesn’t get through (because the network is down, for example), it can take appropriate action - maybe raise an alert, or use a back-up network. This seems counter-intuitive: the most important, time-critical messages are sent at the lowest quality of service. This “QoS paradox” is discussed in more depth in the MQTT Fu article.
MQTT messages do not usually hang around for long in the broker - they are matched against the list of subscriptions and delivered immediately to the subscribers who wish to receive them. If a message is sent at QoS 1 or 2, the message may be held in a queue in the broker for later delivery if a subscriber is not connected at the time the message arrives at the broker. But there is no history of previously sent messages. There is an exception to this: retained messages. Each topic has a buffer for a single message attached to it, which stores the last publication to that topic, if the retain flag is set by the publisher. When a new subscriber subscribes to that topic, if there is a retained message in the buffer, the new subscriber will immediately receive that message (with the retain flag set, so it knows it’s an “old” message, but nonetheless the last published message on that topic). This is a really useful mechanism for giving a new subscriber an immediate view of the current state of play, which then gets updated as new messages start arriving on the topics. For example, if you have a weather dashboard showing data from a weather station, variables like atmospheric pressure don’t change very quickly (maybe every 10 minutes or so). If you did not have retained topics, the pressure indicator would remain blank when you first started up the dashboard, until the next pressure reading was published. With a retained topic, the last published value is sent immediately to the dashboard application when the subscription is placed with the broker, so the application can populate the display with the latest data points from the start.
By a very conscious decision, the only security mechanism defined by the MQTT standard is a simple username and password combination which can optionally be sent in the initial connect message from a client to a broker. These strings appear in plain text in the MQTT message. If you want to secure the MQTT message flows, you should use socket-level encryption (TLS) or a Virtual Private Network (VPN) to secure the link. How the username and password is used by the broker is not defined in the MQTT specification, but is typically used to grant or deny the connection to the broker, and sometimes to control what you can and can’t do, such as which parts of the topic tree you are allowed to publish or subscribe to. You have to get your username and password from the administrator of the broker you are connecting to. For example, if you are connecting to the IBM Watson IoT Platform, you register your device and receive an authorisation key, which you present in the password field of the connect message when your device connects to the broker. By default, many of the current generation of MQTT brokers do not have security turned on, to make it easy to get started, so you do not have to worry about the username/password fields, and can just go ahead and connect. It is strongly recommended that you make use of a broker’s security mechanisms if you run a broker that is visible to the Internet.
Note that the username and password are completely separate from the Client ID, which is also presented in the connect message sent to the broker. The client ID uniquely identifies you to the broker, and if there are any messages waiting to be delivered to you, which arrived while you were disconnected, it is the Client IDwhichtellsthebroker“thisisme,I’mback... haveyougotanythingforme?” There can only be one client using a particular Client ID connected to a broker at any time. Consequently, if you try to connect to a broker using a Client ID that is currently being used by someone else and that is already connected, the existing connection is disconnected by the broker and the new connection with the same Client ID is allowed to connect.
There is a good reason for this, which sometimes seems counter-intuitive at first. A device is connected to the broker with its own unique Client ID. Then the connection fails in some way that makes the broker think the device is still connected (TCP/IP does things like that sometimes). When the device realises there is a problem and tries to reconnect, the desired behaviour is that the new connection attempt succeeds. If the broker took the alternative view and said, no, you’re already connected, you can’t connect, then the “stale” connection with nothing on the client end of it would effectively prevent that device from ever reconnecting.
However, it does mean that if two devices or applications that happen to have the same client ID try to connect at the same time, they will take it in turns to kick the other off the broker, which can result in a “reconnect storm”. For this reason, it is good practice to wait about 5 seconds between reconnect attempts, and to implement logic in your application which looks for a large number of reconnects in a short time and use that to recognise there might be a conflict and stop trying to reconnect, or alert the user in some way.
History of MQTT
In the 1990’s a few oil and gas companies were starting to use publish-and-subscribe messaging in the world of “SCADA” - Supervisory Control and Data Acquisition systems. These are the remote eyes and hands that are used to monitor and control remote pipeline systems; measuring oil flow rates and tem- peratures, gas pressures, valve positions and many other operational parameters that are needed to safely and efficiently run a distribution pipeline network. SCADA also includes the “control” side - turning relays on and off, opening and closing valves, making a pump run faster or slower, etc.
The messaging protocols, or languages, that sensors used in the SCADA world to send data back to the operations centre were almost always in a complex, hard-to-read format that was proprietary to the manufacturers of the devices. For other companies wishing to write software that was compatible with those devices, the protocol specification documents were usually expensive to buy, lengthy, and hard to understand clearly; making inter-operable systems from multiple vendors a difficult feat to achieve.
IBM and their business partner Arcom Control Systems reasoned that if there was just one more protocol - one which all devices could use to communicate, then processing sensor data, adding new sensors, and getting equipment from different manufacturers to work together would be simpler. If that protocol was free and open for everyone to use, then the problems caused by non-interoperable proprietary systems and vendor lock-in would be alleviated.
I (Andy) was then a senior software engineer at IBM in the UK, and Arlen Nipper was President of Arcom Control Systems, a SCADA equipment company in the USA. Together, we decided to tackle this task. Using his experience of protocol design for bespoke SCADA systems, Arlen Nipper designed the first draft of what was then known as “On The Wire Protocol” (OTWP) in May 1998. This was, as the name suggested, a protocol which provided everything required to do messaging over a wired connection that could convey ones and zeros. I led the iterative refinement of the protocol into a publishable form. One of the key design changes, was to replace some of the lower layers of the protocol with TCP/IP. Although, at the time, TCP/IP was not widely used in SCADA networking systems, it was rapidly emerging, and of course, use of TCP/IP and the Internet were growing very rapidly at that time.
Responding to some very valuable feedback from companies in the oil and gas industries, adding some new features such as the “Last Will and Testament” mechanism, and changing the name a couple of times, the first publication of the protocol specification was unveiled in April 1999. The name at that time was
“MQIsdp”: the “Messaging Queuing Integrator SCADA Device Protocol”. This was named after an IBM product, MQ Integrator, which was the first commercial server implementation for the new protocol.
MQTT, as it was later renamed, then standing for Message Queuing Telemetry Transport, started to enjoy limited commercial success for IBM and Arcom. Quite a lot of years passed with Arlen and me spending a lot of time on the road evangelising this new messaging system to oil and gas companies. What became known as the “Arlen and Andy show” involved Arlen Nipper talking about the world from the SCADA engineer’s view, and then me describing the view from the enterprise application end. Of course, the two worlds met at the message broker in the middle, and this elegant “demarcation point” enabled the very separate worlds of SCADA operations and enterprise IT systems to meet and communicate. Today we refer to this as IT/OT integration: Information Technology and Operations Technology.
It rapidly became apparent that MQTT could be used in many industry areas other than for industrial SCADA systems. Early applications appeared in healthcare (a heart rhythm monitor for use in a patient’s home), agriculture (tracking dairy cows in and out of their milking parlour), vehicle telematics (GPS
tracking of delivery vehicles), home automation (electronic mouse traps), and many others. At this point the adoption of MQTT was quite limited, and the “snowball effect” that we had hoped for was not happening. Arlen and I were personally involved in every MQTT project, which clearly wasn’t going to scale when it started to really grow.
Lack of standardisation was hampering adoption of MQTT in certain sectors, particularly government and public sector procurement, and military use, where “is it a recognised standard?” was often a gating factor in procurement processes.
For many years, IBM was the only company with a commercial MQTT broker implementation, which led to the protocol being viewed as “proprietary”, even though the specification had been in the public domain since 1998. This was holding back what we referred to as “our modest plan for world domination”, where every sensor device in the world was connected to TCP/IP and was talking MQTT.
In May 2008, I gave a presentation at OggCamp, an open source “unconference” in the UK. One of the questions from the audience was about whether MQTT was IBM proprietary, or if the software to implement it was open source. In my reply, I acknowledged that the only commercially available implementations of MQTT were from IBM (the client software was free, but not open-source), and IBM had the only broker implementation. But, I confided to the 150 people in the room, if there was an open source MQTT broker implementation, then that would be really cool (and just to clarify, IBM’s lawyers would not have a problem with that). In the audience was Roger Light, a software engineer from Nottingham University. He was inspired by the potential of MQTT from my talk, and went home and registered the project name “mosquitto” (MosQuiTTo) in a software repository, and the first open source MQTT broker implementation was born.
Things moved quickly from that point. The Internet of Things was growing in popularity and capturing people’s interest and imagination. Because of the clear and concise protocol specification, software developers were writing MQTT client implementations in a number of popular programming languages (C, C++, Java, Perl, Python, etc.), and contributing them to open source. The mosquitto message broker was extremely popular and proved remarkably scalable, easily handling a thousand simultaneously connected clients. MQTT was suddenly taking off.
In 2008 a standardisation process through the OASIS standards body took place, led by a number of companies who were making use of MQTT in products and services. The name was changed to just the letters “MQTT”, not “standing for” anything. By 2012, when the Internet of Things was well established, it was usual to connect your Thing to the Internet using either MQTT or HTTP, with XMPP and CoAp trailing behind those two leaders. By 2015, the leading IoT cloud service providers - Amazon, IBM and Microsoft (with no implied ordering) - had all chosen MQTT as their primary connection protocol for devices connectingto their highly scalable cloud-based IoT services. In early 2016, MQTT was submitted for standardisation by the ISO/IEC standards body, emerging as ISO/IEC 20922 later that year. MQTT has arrived!
Note: Update March 2020 - MQTT overtook HTTP as the most used IoT protocol on the internet in 2018, and MQTT v5.0 was approved as an OASIS standard in early 2019.