MQTT

MQTT (Message Queuing Telemetry Transport) is an open OASIS and ISO standard (ISO/IEC 20922) lightweight, publish-subscribe network protocol that transports messages between devices. The protocol usually runs over TCP/IP; however, any network protocol that provides ordered, lossless, bi-directional connections can support MQTT.[1] It is designed for connections with remote locations where a "small code footprint" is required or the network bandwidth is limited.

MQTT
StatusPublished
Year started1999
Latest version5.0[1]
7 March 2019
OrganizationOASIS
CommitteeOASIS Message Queuing Telemetry Transport Technical Committee[2]
EditorsAndrew Banks (IBM), Ed Briggs (Microsoft), Ken Borgendale (IBM), Rahul Gupta (IBM)[1]
Related standardsMQTT-SN[3]
Websitemqtt.org
Internet protocol suite
Application layer
Transport layer
Internet layer
Link layer
  • more...

History

Andy Stanford-Clark (IBM) and Arlen Nipper (then working for Eurotech, Inc.) authored the first version of the protocol in 1999.[4] It was used to monitor oil pipelines[5] within the SCADA framework. The goal was to have a protocol that is bandwidth-efficient, lightweight and uses little battery power, because the devices were connected via satellite link which, at that time, was extremely expensive.[6]

In 2013, IBM submitted MQTT v3.1 to the OASIS specification body with a charter that ensured only minor changes to the specification could be accepted.[2] MQTT-SN (MQTT for Sensor Networks)[7] is a variation of the main protocol aimed at battery-powered[8] embedded devices on non-TCP/IP networks, such as Zigbee. After taking over maintenance of the standard from IBM version 3.1.1 with minor changes[9] was released as an OASIS standard on October 29, 2014.[10][11] A more substantital upgrade to MQTT version 5, adding several new features,[12] was released on March 7, 2019.[1]

Historically, the "MQ" in "MQTT" came from the IBM MQ (then 'MQSeries') MQ product line.[13] However, the protocol provides publish-and-subscribe messaging (no queues, in spite of the name) and was specifically designed for resource-constrained devices and low bandwidth, high latency networks such as dial up lines and satellite links, for example.[14]

In the specification opened by IBM as version 3.1 the formal name was "MQ Telemetry Protocol (MQTT)" but the abbreviation MQTT was used extensively in the text of the specification.[15] In all documents released by OASIS the protocol is strictly referred to as MQTT, although the technical committee itself is named "OASIS Message Queuing Telemetry Transport Technical Committee".[2]

Overview

The MQTT protocol defines two types of network entities: a message broker and a number of clients. An MQTT broker is a server that receives all messages from the clients and then routes the messages to the appropriate destination clients.[16] An MQTT client is any device (from a micro controller up to a fully-fledged server) that runs an MQTT library and connects to an MQTT broker over a network.[17]

Information is organized in a hierarchy of topics. When a publisher has a new item of data to distribute, it sends a control message with the data to the connected broker. The broker then distributes the information to any clients that have subscribed to that topic. The publisher does not need to have any data on the number or locations of subscribers, and subscribers, in turn, do not have to be configured with any data about the publishers.

If a broker receives a message on a topic for which there are no current subscribers, the broker discards the message unless the publisher of the message designated the message as a retained message. A retained message is a normal MQTT message with the retained flag set to true. The broker stores the last retained message and the corresponding QoS for the selected topic. Each client that subscribes to a topic pattern that matches the topic of the retained message receives the retained message immediately after they subscribe. The broker stores only one retained message per topic.[18] This allows new subscribers to a topic to receive the most current value rather than waiting for the next update from a publisher.

When a publishing client first connects to the broker, it can set up a default message to be sent to subscribers if the broker detects that the publishing client has unexpectedly disconnected from the broker.

Clients only interact with a broker, but a system may contain several broker servers that exchange data based on their current subscribers' topics.

A minimal MQTT control message can be as little as two bytes of data. A control message can carry nearly 256 megabytes of data if needed. There are fourteen defined message types used to connect and disconnect a client from a broker, to publish data, to acknowledge receipt of data, and to supervise the connection between client and server.

MQTT relies on the TCP protocol for data transmission. A variant, MQTT-SN, is used over other transports such as UDP or Bluetooth.

MQTT sends connection credentials in plain text format and does not include any measures for security or authentication. This can be provided by using TLS to encrypt and protect the transferred information against interception, modification or forgery.

The default unencrypted MQTT port is 1883. The encrypted port is 8883.[19]

MQTT broker

The MQTT broker is software running on a computer (running on-premises or in the cloud), and could be self-built or hosted by a third party. It is available in both open source and proprietary implementations.

The broker acts as a post office, MQTT doesn’t use the address of the intended recipient but uses the subject line called “Topic”, and anyone who wants a copy of that message will subscribe to that topic. Multiple clients can receive the message from a single broker (one to many capability). Similarly, multiple publishers can publish topics to a single subscriber (many to one).

Each client can both produce and receive data by both publishing and subscribing, i.e. the devices can publish sensor data and still be able to receive the configuration information or control commands (MQTT is a bi-directional communication protocol). This helps in both sharing data, managing and controlling devices.

With MQTT broker architecture, the devices and application becomes decoupled and more secure. MQTT uses Transport Layer Security (TLS) encryption with user name, password protected connections, and optional certifications that requires clients to provide a certificate file that matches with the server’s. The clients are unaware of each others' IP address.

In case of a single source of failure, broker software and clients have an automatic handover to Redundant/automatic backup broker. The backup broker can also be set up to share the load of clients across multiple servers onsite, cloud, or the combination of both.

The broker can support both standard MQTT and MQTT for compliant specifications such as Sparkplug,[20] can be done with same server, same time and with same levels of security.

The broker can store the data in the form of retained messages (need to subscribe with database client) so that new subscribers to the topic can get the last value straight away.

The broker also keeps track of all the session’s information as the devices goes on and off called “persistent sessions”.

The main advantages of MQTT broker are:

  1. Eliminates vulnerable and insecure client connections
  2. Can easily scale from a single device to thousands
  3. Manages and tracks all client connection states, including security credentials and certificates
  4. Reduced network strain without compromising the security (cellular or satellite network)

Message types

Connect
Example of an MQTT connection (QoS 0) with connect, publish/subscribe, and disconnect. The first message from client B is stored due to the retain flag.

Waits for a connection to be established with the server and creates a link between the nodes.

Disconnect

Waits for the MQTT client to finish any work it must do, and for the TCP/IP session to disconnect.

Publish

Returns immediately to the application thread after passing the request to the MQTT client.

MQTT v5.0

In 2019, OASIS released the official MQTT 5.0 standard. Version 5.0 includes the following major new features:[21]

  • Reason codes: Acknowledgements now support return codes, which provide a reason for a failure.
  • Shared subscriptions: Allow the load to be balanced across clients and thus reduce the risk of load problems
  • Message expiry: Messages can include an expiry date and are deleted if they are not delivered within this time period.
  • Topic alias: The name of a topic can be replaced with a single number

Quality of service (QoS)

Each connection to the broker can specify a quality of service measure. These are classified in increasing order of overhead:

  • At most once - the message is sent only once and the client and broker take no additional steps to acknowledge delivery (fire and forget).
  • At least once - the message is re-tried by the sender multiple times until acknowledgement is received (acknowledged delivery).
  • Exactly once - the sender and receiver engage in a two-level handshake to ensure only one copy of the message is received (assured delivery).

[22] This field does not affect handling of the underlying TCP data transmissions; it is only used between MQTT senders and receivers.

Real-world applications

There are several projects that implement MQTT. Examples are:

See also

References
  1. "MQTT Version 5.0". OASIS. 2019-03-07. Retrieved 2020-12-15.
  2. "OASIS Message Queuing Telemetry Transport (MQTT) Technical Committee Charter". OASIS. Retrieved 2020-12-15.
  3. "MQTT SN Subcommittee". OASIS. Retrieved 2020-12-15.
  4. "10th birthday party". MQTT.org. July 2009. Archived from the original on March 15, 2015. Retrieved April 25, 2015.
  5. "Transcript of IBM podcast" (PDF). IBM.com. November 2011. Retrieved January 7, 2021.
  6. "Getting Started with MQTT". HiveMQ. 2020-04-24.
  7. Stanford-Clark, Andy; Hong Linh Truong (November 14, 2013). "MQTT For Sensor Networks (MQTT-SN) Protocol Specification Version 1.2" (PDF). oasis-open.org. OASIS Message Queuing Telemetry Transport (MQTT) Technical Committee. p. 28. Retrieved 2020-12-15.
  8. "Introduction to MQTT-SN (MQTT for Sensor Networks)". Retrieved 2020-09-16.
  9. "Differences between 3.1.0 and 3.1.1". Retrieved 2020-12-16.
  10. "MQTT Version 3.1.1". 2014-10-29. Retrieved 2020-12-16.
  11. "6 facts why it's worth upgrading to the brand new MQTT 3.1.1 version". 2014-10-30. Retrieved 2020-12-16.
  12. "Differences between 3.1.1 and 5.0".
  13. "IBM MQ". IBM. Retrieved November 18, 2013.
  14. Piper, Andy (February 19, 2013). "Choosing Your Messaging Protocol: AMQP, MQTT, or STOMP". blogs.vmware.com. VMware Blogs. p. 1. Retrieved October 23, 2013.
  15. "MQTT V3.1 Protocol Specification". Eurotech, International Business Machines Corporation (IBM). 2010. Retrieved 2020-12-15.
  16. Yuan, Michael. "Getting to know MQTT". IBM Developer. Retrieved 13 October 2019.
  17. "Client, Broker / Server and Connection Establishment - MQTT Essentials: Part 3". hivemq.com. Retrieved 13 October 2019.
  18. "Retained Messages - MQTT Essentials: Part 8". hivemq.com. Retrieved 13 October 2019.
  19. "FAQ - Frequently Asked Questions | MQTT". Retrieved 2020-03-19.
  20. "MQTT Sparkplug/Tahu". www.cirrus-link.com. Retrieved November 5, 2019.
  21. "What is MQTT? Definition and Details". www.paessler.com. Retrieved 2020-06-09.
  22. "IBM Knowledge Center - IBM MQ - Using MQTT with IBM Integration Bus - Quality of service and connection management". www.ibm.com. Retrieved 2018-01-30.
  23. Saxena, S.; Jain, S.; Arora, D.; Sharma, P. (13 February 2020). "Implications of MQTT Connectivity Protocol for IoT based Device Automation using Home Assistant and OpenHAB". 2019 6th International Conference on Computing for Sustainable Global Development (INDIACom): 475–480.
  24. "MQTT - Bindings". www.openhab.org. Retrieved 2020-11-10.
  25. Brothers, Reginald (January 25, 2016). "S&T's Internet of Things Pilot Demonstrates 'State of the Practical'". dhs.gov. p. 1. Retrieved March 31, 2016.
  26. "The story of MQTT Buddy begins!". mqtt.ximxim.com. XIM, Inc. February 24, 2017. p. 1. Archived from the original on July 23, 2017. Retrieved July 1, 2017.
  27. "MQTT Buddy". mqtt.ximxim.com. XIM, Inc. Archived from the original on March 21, 2018. Retrieved July 1, 2017.
  28. Community staff writer (June 14, 2016). "Version 0.14 released". nodered.org/blog. Node-RED. Retrieved July 6, 2016. MQTT with TLS support
  29. Home Assistant Community (August 7, 2015). "MQTT". home-assistant.io. Home Assistant Community. Retrieved August 4, 2017.
  30. Home Assistant Community (August 7, 2015). "MQTT Brokers". home-assistant.io. Home Assistant Community. Retrieved August 4, 2017. The MQTT component needs you to run an MQTT broker for Home Assistant to connect to. There are four options, each with various degrees of ease of setup and privacy.
  31. ProcessOne, Marek Foss (2019-02-26). "ejabberd 19.02: the MQTT Edition". ProcessOne — Blog. Retrieved 2019-03-04.
  32. Eastburn, Josh (2020-08-24). "How to Integrate Automation Data with MQTT-Sparkplug B". Manufacturing Business Technology. Retrieved 2020-09-01.
  33. Guindon, Christopher (2020-01-29). "Frequently Asked Questions". Eclipse Sparkplug. Retrieved 2020-09-01.


This article is issued from Wikipedia. The text is licensed under Creative Commons - Attribution - Sharealike. Additional terms may apply for the media files.