MQTT Essentials: Part 1 – Introducing MQTT

MQTT Essentials - Introducing MQTT

Welcome to the first part of MQTT Essentials. A blog series about the core features and concepts in the MQTT protocol. This post introduces the MQTT Essentials series and what we’ll cover on the blog in 2015. Also it will give an introduction to MQTT and some general information and background on the protocol.

Announcing the MQTT Monday!

The beginning of a year is always great to start new things, so in that motivational spirit, we want to change our blogging concept and feature more posts about MQTT in general. We have a lot of different topics in mind from the now starting essentials series to an in-depth look on security or client libraries. So if your interested in MQTT you should definitely check our blog regularly or sign up for our newsletter to get new posts directly to your inbox, when they are published.

Together with this first post, we will also introduce the MQTT Monday. Every Monday we will publish a new blog post regarding MQTT. So you can expect a new part of the Essentials series each upcoming Monday. We hope that the content of these post will help MQTT users of any knowledge level to quickly understand and implement MQTT in their projects and use cases.

MQTT Essentials: Why and what we are going to cover?

Before covering today’s topic, we want to explain why we have decided to write the series, who is it for and what topics will be covered. We are working with MQTT for a long time, over 3 years now, and we have answered basic questions about the core concepts like publish/subscribe, quality of services and many others a lot on different platforms (customers, conferences, online). So with the MQTT Essentials we like to cover the main pillars as a reference guide for users of all kind. MQTT is an open protocol and therefore the information on how to use it should also be open and accessible to anybody, who’s interested.
We are very excited about this and hope you’ll find this content useful.

Now what will be in the MQTT Essentials and what won’t? At first we will cover basic concepts of MQTT (publish/subscribe, client/broker) and basic functionality (Connect, Publish, Subscribe). After that we will look at features like Quality of Service, Retained Messages, Persistent Session, Last Will and Testament and SYS Topics one by one. The whole series will be around 10 individual posts. What we explicitly excluded in the Essentials is security. We know that this is a very important topic and shouldn’t be neglected. That’s why we plan a separate series just about MQTT and Security sometime after the Essentials.

Introducing 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 in describing what MQTT is all about. It is very light weight and binary protocol, which excels when transferring data over the wire in comparison to protocols like HTTP, because it has only a minimal packet overhead. Another important aspect is that MQTT is extremely easy to implement on the client side. This fits perfectly for constrained devices with limited resources. Actually this was one of the goals when MQTT was invented in the first place.

A little bit of history

MQTT was invented by Andy Stanford-Clark (IBM) and Arlen Nipper (Arcom, now Cirrus Link) back in 1999, when their use case was to create a protocol for minimal battery loss and minimal bandwidth connecting oil pipelines over satellite connection. They specified the following goals, which the future protocol should have:

  • Simple to implement
  • Provide a Quality of Service Data Delivery
  • Lightweight and Bandwidth Efficient
  • Data Agnostic
  • Continuous Session Awareness

These goals are still the core of MQTT, while the focus has changed from proprietary embedded systems to open Internet of Things use cases. Another thing that is often confused about MQTT is the appropriate meaning of the abbreviation MQTT. It’s a long story, the short answer is that MQTT officially does not have an acronym anymore, it’s just MQTT.

The long story is that the former acronym stood for:

MQ Telemetry Transport

While MQ is referencing to MQ Series, a product developed by IBM which supports MQTT and the protocol was named after, when it was invented 1999. Often MQTT is incorrectly named as message queue protocol, but this is not true. There are no queues as in traditional message queuing solutions. However, it is possible to queue message in certain cases, but this will be discussed in detail in a later post. So after MQTT had been used by IBM internally for quite some times, version 3.1 was released royalty free in 2010. From there on everybody could implement and use it. We were introduced to it in 2012 and build the first version of HiveMQ in the same year, before releasing it to the public in 2013. But not only the protocol specification was released also various client implementation were contributed to the newly founded Paho project underneath the Eclipse Foundation. This was definitely a big thing for the protocol, because there is little chance for wide adoption when there is no ecosystem around it.

OASIS Standard and current version

Around 3 years after the initial publication, it was announced that MQTT should be standardized under the wings of OASIS, an open organization with the purpose of advancing standards. AMQP, SAML, DocBook are only a few of the already released standards. The standardization process took around 1 year and on October 29th 2014 MQTT was officially approved as OASIS Standard. MQTT 3.1.1 is now the newest version of the protocol. The minor version change from 3.1 to 3.1.1 symbolizes that there where only little changes made to the previous version. The primary goal was to deliver a standard as soon as possible and improve MQTT from there on. For detailed information about the changes, see our blog post about why it’s worth to upgrade to 3.1.1.

We would definitely recommend to use MQTT 3.1.1.


So that’s already the end of part 1 in our multi-part series of MQTT Essentials. We hope you did enjoy it and learned something new about MQTT. If you have any feedback or questions we should answer, while covering future topics in the next posts, let us know in the comments. By the way the topic of next week will be a introduction into the publish and subscribe pattern as well as explaining the difference between MQTT and a message queue.

If you want to be notified as soon as the next part is released simply sign up for our newsletter, which brings you fresh content about MQTT and HiveMQ once a week. If you prefer RSS, you can subscribe to our RSS feed here.

13 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.

Leave a Reply

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