MQTT Essentials: Part 1 – Introducing MQTT

MQTT Essentials - Introducing MQTT

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, we contributed 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. MQTT 3.1.1 is the newest version of the protocol. 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.

We strongly recommend use of MQTT 3.1.1.


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.

16 comments

  1. henil says:

    we are providing home automation solution………our requirements are as below.

    1) controllers and mobile devices will able to publish and subscribe to server for messages

    2) How can we design MQTT server for that purpose ?

    1. Hi henil,

      this sounds like a common MQTT requirement. Regarding the MQTT server design: I’d just go for a cloud provider like AWS and install HiveMQ on EC2. This is trivial to install. This allows to scale to a vast amount of MQTT clients.

      Contact us via e-mail if you want to talk to us about your requirements!

      Hope this helps,
      Dominik from the HiveMQ Team

  2. sb4 says:

    Are my eyes defective, or is an explanation of what MQTT stands for universally missing from almost every documentation including this one?

    1. Hi sb4,

      What exactly do you mean?
      “MQTT officially does not have an acronym anymore, it’s just MQTT”, see the section “A little bit of history” in the post above.

      Hope that helps,
      Christian from the HiveMQ Team

  3. abha says:

    Hi,
    MQTT is lack of interoperability. I am not getting it who is responsible for data format in case publisher and subscriber.
    Please let me know, if you have idea.

    Thanks,
    Abha

    1. Hallo Abha,

      MQTT allows does not restrict what kind of data you send.
      Inside your application you can send and receive any kind of data you wish.

      Hope that helps.

      Florian, from the HiveMQ Team.

  4. abha says:

    Hi Florian,
    thank you for reply
    Actually I got to know that MQTT is not aware about payload or internal structure of message format. but i little bit confuse about where it convert as binary like temperature 58 f . publisher convert in binary and send it or MQTT gateway itself.
    how to know about temperature in f or c to subscriber. or it is well know in advance.
    thanks
    abha,

    1. Hi Abha,

      any information about how to interpret the payload is not part of the MQTT layer.
      There is multiple possibilities to achieve what you describe.
      For example you can send an F or a C with the payload or have your setup only transmit either Fahrenheit or Celsius values, etc …

      I hope this helps.

      Florian, from the HiveMQ Team.

  5. Nigel Trewartha says:

    If I ant to send to different devices with different programming languages – and therefor different representation of data – I suppose I could send data in XML?

    1. Hallo Nigel,

      Per definition MQTT is ‘A messaging transport that is agnostic to the content of the payload.’
      So yes, using XML is a viable approach.

      Hope that helps.

      Best regards,
      Florian, from The HiveMQ Team.

  6. Rahul Kaushik says:

    Can we use python for coding?

    1. Hi Rahul,

      you can find example python code in the MQTT Client Library Encyclopedia:
      https://www.hivemq.com/blog/mqtt-client-library-paho-python

      Regards,
      The HiveMQ Team

    2. Hi Rahul,

      Nice to see you are taking an interest in MQTT.
      For example this library can be used in Python.

      Kind regards,
      Florian

Leave a Reply

Your email address will not be published. Required fields are marked *