Introducing the MQTT Protocol - MQTT Essentials: Part 1
Written by The HiveMQ Team
Published: January 12, 2015
Welcome to MQTT Essentials: A ten-part blog series on the core features and concepts of the MQTT protocol. This post outlines what we plan to cover in the blog, gives you a quick introduction to MQTT, and provides some interesting background material on the protocol.
Meet MQTT Monday!
The beginning of a year is a great time to start new things. In that spirit, we’re stepping things up in our blog to cover a broader range of MQTT topics. From this new essentials series to an in-depth look at security and client libraries, there is a lot of great content headed your way. Every Monday, we’ll publish a fresh new blog post about MQTT. So, if you are interested in MQTT, check our blog regularly. Better yet, sign up for our newsletter and get new posts delivered straight to your inbox as soon as they are available.
We hope that these posts will make it easier for you to understand and implement MQTT quickly and successfully.
MQTT Essentials: Why, what, and what not:
Before we dive into today’s topic, let me explain why we are doing this series, who the intended audience is, and what we’ll cover in the days to come. The HiveMQ team has been working with MQTT for a long time. Our experts answer questions about the core concepts of MQTT to customers, at conferences, and online every day. These questions concern publish/subscribe, quality of services, and many others topics. In the MQTT Essentials series, we want to explain the main concepts of MQTT and offer an easily accessible reference guide for users of all kinds. MQTT is an open protocol and we believe that information on how to use it needs to be open as well. We’re very excited about this technology and hope that you find this content useful.
First, we’ll explore the basic concepts (publish/subscribe, client/broker) and basic functionality (Connect, Publish, Subscribe) of MQTT. Then, we’ll look at the features: Quality of Service, Retained Messages, Persistent Session, Last Will and Testament, Keep Alive and more.
What you won’t find in the Essentials series is security information. Security is a big topic in MQTT. In fact, it is such an important topic that we have developed a completely separate series about MQTT and security to follow this series.
Inroduction to MQTT
“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
The abstract of the MQTT specification does a good job describing what MQTT is all about. It is a very light weight and binary protocol, and due to its minimal packet overhead, MQTT excels when transferring data over the wire in comparison to protocols like HTTP. Another important aspect of the protocol is that MQTT is extremely easy to implement on the client side. Ease of use was a key concern in the development of MQTT and makes it a perfect fit for constrained devices with limited resources today.
A little bit of history
The MQTT protocol was invented in 1999 by Andy Stanford-Clark (IBM) and Arlen Nipper (Arcom, now Cirrus Link). They needed a protocol for minimal battery loss and minimal bandwidth to connect with oil pipelines via satellite. The two inventors specified several requirements for the future protocol:
- Simple implementation
- Quality of Service data delivery
- Lightweight and bandwidth efficient
- Data agnostic
- Continuous session awareness
These goals are still at the core of MQTT. However, the primary focus of the protocol has changed from proprietary embedded systems to open Internet of Things (IoT) use cases. This shift in focus has created a lot of confusion about what the acronym MQTT stands for. The short answer is that MQTT is no longer considered an acronym. MQTT is simply the name of the protocol.
The longer answer is that the former acronym stood for MQ Telemetry Transport.
“MQ” refers to the MQ Series, a product IBM developed to support MQ telemetry transport. When Andy and Arlen created their protocol in 1999, they named it after the IBM product. Many sources label MQTT incorrectly as a message queue protocol. That is simply not true. MQTT is not a traditional message queuing solution (although it is possible to queue messages in certain cases, a fact that we discuss in detail in an upcoming post). Over the next ten years, IBM used the protocol internally until they released MQTT 3.1 as a royalty-free version in 2010. Since then, everyone is welcome to implement and use the protocol.
We became acquainted with MQTT in 2012 and built the first version of HiveMQ that very same year. In 2013, we released HiveMQ to the public. Along with the release of the protocol specification, IBM contributed MQTT client implementations to the newly founded Paho project of the Eclipse Foundation. These events were definitely a big thing for the protocol because there is little chance for wide adoption without a supportive ecosystem.
OASIS Standard and current version
Approximately 3 years after the initial publication, it was announced that MQTT would be standardized under the wings of OASIS, an open organization with the purpose of advancing standards. AMQP, SAML,and DocBook are just a few of the previously released OASIS standards. The standardization process took around 1 year. On October 29, 2014 MQTT became an officially approved OASIS Standard. The minor version change from 3.1 to 3.1.1 shows that few changes were made to the previous version. For detailed information about these changes, see our blog post on the advantages of 3.1.1.
In March 2019, OASIS ratified the new MQTT 5 specification. This new MQTT version introduced new features to MQTT that are required for IoT applications deployed on cloud platforms, and those that require more reliability and error handling to implement mission-critical messaging. To learn more about MQTT 5, please check out our MQTT 5 Essentials blog series.
We strongly recommend use of MQTT 5.
That brings us to the end of part 1 in our multi-part series of MQTT Essentials. We hope you enjoyed this introduction and learned something new about MQTT. Thanks for joining us and be sure to check back next week for our introduction to the publish and subscribe pattern and the differences between MQTT and a message queue.
If you have any feedback or questions, please let us know in the comments.
To get the next part of this series as soon as it is released, enter your email in the subscription form below. If you prefer RSS, you can subscribe to our RSS feed here.