The lightweight messaging protocol for IoT
Previously We have already understand basic concept regarding the Internet of Things (IoT), including what IoT is, what technologies make IoT possible and current implementations of IoT in our society. In this article let's know something new - MQTT - one of the most commonly used protocols that supports the IoT.
Let's get started.
Previous article:
Table of Contents
- What is MQTT?
- What are other protocols used for IoT?
- Broker-Clients architecture
- MQTT use-cases?
What is MQTT?
Message Queuing Telemetry Transport Protocol(MQTT) is one of the oldest open-source pub/sub M2M communication protocols, which was introduced in 1999 by Andy Stanford-Clark and Arlen Nipper.
MQTT is efficient in its utilization of bandwidth and system resources. As a result, it is popular in use cases ranging from low-powered embedded systems to cloud-native micro-service.
What are other protocols used for IoT?
Other widely accepted protocols are Constrained Application Protocol (CoAP), Advanced Message Queuing Protocol (AMQP), and HyperText Transport Protocol (HTTP). Different protocols are being used in different scenarios. Researchers have made comparisons based on some interrelated
criteria to gain insight into their strengths and limitations (see article). While in this article let's focus on MQTT.
Broker-Clients architecture
In MQTT protocol there are two major entities: a broker and clients.
An MQTT broker is a central software entity in the MQTT architecture. It acts just like a real estate broker which first does background checks on the parties involved and then after making sure that the relevant rules are enforced, the broker initiates a transaction.
An MQTT broker does the same thing but instead of monetary transactions, MQTT brokers handle message transactions. Specifically, here’s how MQTT brokers facilitate transactions between MQTT clients:
- Allow devices (a.k.a. “client devices” or simply “clients”) to make a connection request
- Authenticate the devices based on the connection information shared by the connecting device(s)
- Once authenticated, make sure that the device can send/receive messages to/from other devices securely using Transport Layer Security (TLS) encryption (as one option)
- Stores messages within the server so that they could be re-sent in the case of unwanted connection loss, on client-connect, on client-disconnect, etc. As an MQTT broker allows devices (clients) to communicate in a decoupled way, the complete architecture can be scaled very easily without even affecting existing client devices.
Because the MQTT broker is a central entity and does all of the heavy lifting, the client devices only have to do minimal processing with minimal bandwidth.
Now let’s take a closer look at how those client devices work. Clients can be almost any “smart” device including smartphones, web apps, sensor nodes, actuators, or even smartwatches. Clients can:
- Connect to a broker with a username and password
- Subscribe to a topic (listen for messages published to that topic)
- Publish to a topic (send a message(s) to that topic)
MQTT use-cases?
- Collecting data from sensor nodes and publishing it to the server
- Publishing mission-critical data directly from a sensor node to a user device
- Configuring IoT and IIoT devices remotely
- Sending configuration data from a single web platform or smartphone app to all devices at once (thanks to the MQTT topics which allow wildcards)
- Instantly pushing OTA(over-the-air) updates to all the devices in the network
References
https://searchengineland.com/6-ways-iot-will-make-local-search-smbs-scalable-283750
https://www.catchpoint.com/network-admin-guide/mqtt-broker
https://ieeexplore.ieee.org/stamp/stamp.jsp?tp=&arnumber=8088251&tag=1
https://medium.com/swlh/android-and-mqtt-a-simple-guide-cb0cbba1931c
Top comments (0)