Introduction to MQTT

MQTT (Message Queuing Telemetry Transport) is an instant messaging protocol developed by IBM. It is designed with lightness, openness, simplicity, and specification in mind, and is therefore easy to implement. These features make it a good choice for many scenarios, including constrained environments such as machine-to-machine communication (M2M) and Internet of Things environments (IoT) that require very small code packages or very expensive network bandwidth.

The MQTT protocol is a protocol designed for the communication of a large number of remote sensors and control devices with limited computing power and operating on low-bandwidth, unreliable networks, and has several key features, as follows.

  • Use Publish/Subscribe messaging model to provide one-to-many message distribution and decouple applications
  • Messaging with load content masking
  • Use TCP/IP to provide network connectivity
  • There are three message publishing service qualities
    • “At most once”, message distribution is completely dependent on the underlying TCP/IP network. Message loss or duplication can occur. This level can be used in the following cases, environmental sensor data, where it does not matter if a read record is lost once, because a second send will occur shortly afterwards.
    • “At least once” to ensure that the message arrives, but message duplication may occur.
    • “Only once” to ensure that the message arrives once. This level can be used in the following cases, where message duplication or loss can lead to incorrect results in a billing system
  • Small transmissions with minimal overhead (fixed-length headers are 2 bytes) and minimal protocol switching to reduce network traffic
  • Mechanisms for notifying interested parties of abnormal client outages using Last Will and Testament features

Simply put, the MQTT protocol is a lightweight instant messaging protocol. Because it is used in environments where the hardware and network are not so good, it does not require too much equipment to adapt to difficult environments. It also has to ensure the quality of message delivery, so there are three release quality modes (QoS)

It is natively conditioned on the application layer protocol based on TCP/IP to shield the specific data interaction format of message transmission. That is, do not care how the underlying layer is transmitted, what format is used for data transmission in the field of the Internet of Things (IoT, Internet of Things) will have a big development in the future.

Background of MQTT development

Data transmission in IoT will face many problems, such as how to ensure that data is transmitted without problems when the network is unstable, how to ensure that data is not sent repeatedly, and how to reconnect when the connection is disconnected. In general, IoT access will face challenges in the following areas.

  • Devices, sensors. IoT access has high requirements for terminal collection and control devices, and the transformation of terminals and the cost of network expenses are also relatively high. In addition, its energy consumption requirements for terminals are also relatively high.
  • Network. The existing network transmission loans are uneven and the transmission network is unstable.
  • Server. The access capability of multiple clients in the case of high concurrency and the message processing capability.

History of MQTT

In IoT, open source and open standards are essential elements. the history of MQTT development is roughly as follows.

  • In 1999, IBM and partners co-invented the MQTT protocol.
  • In 2004, org opened the forum for broad participation.
  • In 2011, IBM established the Eclipse open source project Paho and contributed code. Eclipse Paho is a Java implementation of MQTT.
  • In 2013, the OASIS MQTT Technical Specification Committee was formed.
  • In 2014, MQTT officially became the recommended IoT transport protocol standard.

MQTT protocol

Currently MQTT is used by everyone for mobile push, such as FacebookMessenger, and is suitable for mobile application devices because of its small size, power saving, low protocol overhead and ability to efficiently deliver messages to one and multiple recipients. The protocol is simple, with a minimum header of 2 bytes. Compared to XMPP, MQTT is more lightweight and consumes less bandwidth by the user. The overall protocol can be split into: fixed header + variable header + message body

MessageType(0 and 15 reserved, 4 bytes in total)

  • “MQTT_CONNECT”=>1,//request for connection
  • “MQTT_CONNACK”=>2,//Request for answer
  • “MQTT_PUBLISH”=>3,//publish message
  • “MQTT_PUBACK”=>4,//Publish answer
  • “MQTT_PUBREC”=>5,//publish has been received, guaranteed to pass 1
  • “MQTT_PUBREL”=>6,//released, guaranteed to pass 2
  • “MQTT_PUBCOMP”=>7,//Release completed, pass 3 guaranteed
  • “MQTT_SUBSCRIBE”=>8,//subscription request
  • “MQTT_SUBACK”=>9,//subscription answer
  • “MQTT_UNSUBSCRIBE”=>10,//unsubscribe
  • “MQTT_UNSUBACK”=>11,//unsubscribe to answer
  • “MQTT_PINGREQ”=>12,//ping request
  • “MQTT_PINGRESP”=>13,//ping response
  • “MQTT_DISCONNECT”=>14/disconnect

DUP flag

Used to ensure reliable message transmission, if set to 1, the MessageId is added to the following variable header, and requires a reply confirmation to ensure that the message transmission is complete, but can not be used to detect duplicate messages sent.

Qos

Mainly used for PUBLISH (publish state) messages, to ensure the number of times the message is delivered.

  • 00 means at most once i.e. <=1
  • 01 means at least once i.e. >=1
  • 10 means once, i.e. == 1
  • 11 is reserved and followed by

Retain

Mainly used for PUBLISH (publish state) messages, indicating that the server wants to keep this push and push this message to it if a new subscriber appears. If not set then push to the currently subscribed is released.

Fixed header byte 2

is used to save the total size of the next variable header + message body. But it can not be saved directly, and is also scalable, the mechanism is the first 7 bits are used to save the length, the latter part is used for identification.

I gave an example, that is, if the size of the back of the calculation for 0 < length <= 127, normal preservation; if it is 127 < length < 16383, it is necessary to save two bytes, the first byte of the largest one position 1, that is, unfinished. Then the second byte continues to store.

Take 130, the first byte to store 10000011, the second byte to store 000000001, that is, 0x83, 0x01, the two bytes together to see, the second byte weight from 2 of 8 times to start. The same can be added to the third byte, up to the fourth byte. Therefore, the MQTT protocol can achieve up to 268 435 455 (0xFF, 0xFF, 0xFF, 0x7F) nearly 256M of data. It is possible to stretch and shrink.

Using MQTT

The architecture of the MQTT protocol is illustrated with an example. Let’s say there is 1 temperature sensor (1 Machine), 2 small displays (2 Machines) and the display has to show the temperature value of the temperature sensor. Details of the detailed specification are available via MQTT V3.1 Protocol Specification.

The display needs to first subscribe to a topic called temperature via the MQTT protocol.

When the temperature sensor publishes (publishes) the temperature data, the display can receive it.

There are 2 other main roles in the protocol.

  • client, the client side
  • broker, the server side

They are connected via the TCP/IP protocol. Because MQTT is a protocol, it cannot be used directly, as if it were the HTTP protocol. You need to find a library or server that implements this protocol to run it.