MQTT Protocol : Architecture & lots more
MQTT is also a protocol like HTTP. It was very fresh and astonishing for me too when I learned about MQTT. We will cover these amazing points about MQTT at the end of this blog.
- What is MQTT ?
- Avails of MQTT protocol
- MQTT Components and Architecture
- MQTT v/s HTTP
- MQTT Applications and Real time usage.
What is MQTT ?
MQTT (Messaging Queue Telemetry Transport) is a protocol prominently used for machine to machine data transfer in the IoT (Internet of things) domain. In very simple terms I can say it’s a lightweight publish / subscribe protocol which enables distributed design architecture for communication between embedded devices.
Publish: When the device sends the data to the server or broker, then the operation is called publish.
Subscribe : When the client receives the data from the broker, then we call this operation as Subscription.
Avails of MQTT Protocol
- Takes less bandwidth and memory : It is a lightweight protocol to install and even can run on devices having low CPU and RAM. It results in smooth transmission of the data in comparison to other protocols like HTTP and AMQP.
- Bidirectional: Amazing experience for me about MQTT is it allows messages in both directions, either from client to server or server to client.
- Reliable: MQTT follows a very high standard on reliability since there are many cases of messages delivery in the IoT domain. That is the main reason it is having QOI(quality of index) values as 0, 1, 2. In subsequent parts of this blog, we will discuss this topic.
- Feasible for Remote Application: The major goal of this protocol is to enable connections for remote places where just a little amount of code is required and network capacity is constrained.
MQTT Components and Architecture
MQTT Components :
- Message
- Client
- Server or Broker
- Topic
1) Message:
Message is nothing but the data, which is going to be transferred over the network using MQTT.
These 4 parameter comes in message:
a) Payload Data : Each message bundle contains a structured payload in it. Normally JSON and XML can be sent as payload which can be read by other devices.
b) Quality of Index(qos): Administration can increase the reliability of successful transfer of the message by QoS parameter.
- qos (0) : No guarantee of delivery since receiver does not acknowledge the message received. Senders also do not send that message. It is like fire and forget.
- qos (1) : Receiver acknowledge the message which is received. If the sender does not get the acknowledgement it will resend the message. Receiver can get two duplicate messages.
- qos (2) : When sender sends the message with qos 2, at receiver side acknowledgement will be sent to the receiver same like qos 1, but with qos 2 duplicate message will not be entertained or received back by the receiver.
All messages sent with QoS 1 and 2 are queued for offline clients until the client is available again if the client’s session is persistent.
c) Collection of Properties
d) Topic Name
2) Client:
Any device which is getting or sending data from the broker is termed as Client in MQTT. It can have two roles: PUBLISH/SUBSCRIBE.
To get the message from the broker, client needs to subscribe to the broker on a specific topic and to publish the message from the client to the broker, the topic should be specified.
3) Server/Broker:
Broker receives messages from devices and sends messages to clients. Devices/Clients who send the message to the broker are called publisher clients and devices who receives the messages from broker are called subscriber clients.
I learned that broker is the central point of communication through which every message should pass and it can be connected to multiple client devices on which the messages need to be sent.
Broker stores the messages in message queue and send the message in FIFO(first in first out) pattern and also it manages authentication and authorization of the Client.
4) Topic:
Topic is a very important component I believe because it is an identity on which a specific type of payload/message can be subscribed by client and issued from server. It seems same as URI in HTTP protocol.
Topics are represented with strings separated by a forward slash. Each forward slash indicates a topic level.
MQTT v/s HTTP
MQTT Applications and Real Time usage.
Applications use message queueing telemetry transport (MQTT) to function are:
- Smart Cities : Smart cities which include ( smart transport, smart healthcare, smart school, smart meter and smart home) required to set up a quick, faster and standard communication protocol like MQTT.
- Remote area Sensors : Sensor based devices / application installed at remote area which regularly sends the messages to its server required to run at low bandwidth internet and low cost infrastructure setup. The MQTT protocol suits these types of applications.
- Wearable Devices : To make data transmission in low energy wearable devices like smart watches, smart shoes etc.
- Social Media Applications : Facebook using MQTT protocol for transmission for its Instagram and Messenger applications. It takes low bandwidth and battery of the device.
- Smart Farming : Real time information of weather, sunlight, soil pH, moisture, humidity we can get from different MQTT enabled IoT devices, these information can make farming effective.
- Manufacturing : IoT devices have various sensors that can monitor the temperature, vibration, voltage, currents, and more. So, these MQTT enabled sensors can help with early warning signs of any predicted malfunctions, or downtime.
- Smart Home Automation : MQTT enabled home devices can enhance the energy efficiency, security and cost savings of the home. IoT enabled smart devices can send data to broker and data on the broker can be read by any mobile application.
