MQTT Protocol

MQTT = Message Queuing Telemetry Transport Telemetry = Tele-Metering = Remote Measurements
Originally Developed by IBM, now Open Sourced.
Though MQ stands for ‘Message Queuing’, actually there’s NO Messages being Queued.
It’s a Publish/Subscribe mechanism.
- Sensor Devices Publish data to the Topics/Servers/Brokers.
- Topics are subscribed by other devices such as mobile devices those are looking for data from Sensors.
Low Bandwidth Protocol
- Messages being sent by devices are very small in bytes.
- e.g. Temperature sensor sending 100 degree reading.
Small Code Footprint
- The code used for this is very small.
Used in:
- Facebook Messenger for iOS and Android
- PubNub

MQTT Ports

Protocol: TCP/IP
Ports:
- 1883 - non-encrypted communication
- 8883 - encrypted communication

Maximum Payload Size

MQTT Protocol Max Payload - 256 MBs
AWS IoT MQTT Max Payload - 128 KBs

Quality of Service

Levels:
0 = At Most Once (Best effort, No Ack)
- Sender does not store messages, neither the receiver sends any acknowledgement.
- This method requires only one message and once the message is sent to the broker by the client it is deleted from the message queue.
- Therefore QoS 0 nullifies the chances of duplicate messages, which is why it is also known as the fire and forget method.
- It provides a minimal and most unreliable message transmission level that offers the fastest delivery effort.

1 = At Least Once (Acknowledged, Retransmitted if Ack not received)
- Using QoS 1, the delivery of a message is guaranteed (at least once, but the message may be sent more than once , if necessary).
- This method needs two messages.
- Here, the sender sends a message and waits to receive an acknowledgment (PUBACK message).
- If it receives an acknowledgment from the client then it deletes the message from the outward-bound queue.
- In case, it does not receive a PUBACK message, it resends the message with the duplicate flag (DUP flag) enabled.

2 = Exactly Once
- The QoS 2 level setting guarantees exactly-once delivery of a message.
- This is the slowest of all the levels and needs four messages.
- In this level, the sender sends a message (PUBLISH) and waits for an acknowledgment (PUBREC message).
- The receiver also sends a PUBREC message.
- If the sender of the message fails to receive an acknowledgment (PUBREC), it sends the message again with the DUP flag enabled.
- Upon receiving the acknowledgment message PUBREC, the sender transmits the message release message (PUBREL).
- If the receiver does not receive the PUBREL message it resends the PUBREC message.
- Once the receiver receives the PUBREL message, It forwards the message to all the subscribing clients.
- Note: For Sender Broker is the receiver and for Receiver Broker is the sender.
- Thereafter the receiver sends a publish complete (PUBCOMP) message.
- In case the sender does not receive the PUBCOMP message, it resends the PUBREL message.
- Once the sending client receives the PUBCOMP message, the transmission process is marked as completed and the message can be deleted from the outbound queue.
these messages are same as used in WiFi communication.

Retained Messages

Server keeps messages even after sending it to all Subscribers.
New Subscribers get the retained messages.
- We had seen this behavior in PubNub, where last message Published to Channel was retained till the next message is Published to that channel.
- This Last message was available to new subscriber.
- Only One Message is retained per Topic.
- Usecase:
  - Sensor periodically sending a message on a topic. New subscriber will get the last state of the sensor with Retained message.
- Reference: MQTT Retained Messages Explained

Clean Session and Durable Session

Clean Session:
- Clean Session Flag = 1 [Optional]
- All of the client’s subscriptions are removed when it disconnects from the server.
Durable Session:
- Clean Session Flag = 0 [Optional]
- The client’s subscriptions remain in effect after any disconnection.
- In this event, subsequent messages that arrive carrying a High QoS designation are stored for delivery after the connection is reestablished.

Retained messages, Clean Session and QoS inter-related behavior
Reference: MQTT Retained Messages Explained

Wills

A Will or a Message is informed by client with server that should be published to a specific Topic or Topics in the event of an unexpected disconnection.
A Will is an alarm or security settings where system when a remote sensor has lost contact with the network.

Keep Alive Messages

Periodically sent

Topic Trees, Strings

Topics are organized Hierarchically into Topic Trees, using the ‘/’ character to create subtopics in the Topic String.
Topic String
- A character string that identifies the Topic of a publish/subscribe message.
- Topic strings can contain either of two Wildcards:
- These WildCards Allows subscribers to match patterns within strings defined by message publishers
- Wildcard: #:
  - Multilevel
  - used to match any number of levels within a Topic.
    - e.g. subscribers to truck/contents/# receive all messages that are designated for the topics:
    - truck/contents
    - truck/contents/rfid
- Wildcard: +:
  - Single Level
  - used to match Just ONE Topic Level.
    - e.g. truck/+ matches truck/contents but not truck/contents/rfid

MQTT Essentials - All key features of MQTT

MQTT Brokers Comparison

Stress-Testing MQTT Brokers: A Comparative Analysis of Performance Measurements:
- Tested Borkers:
  - Mosquitto - Bevywise MQTT Route - ActiveMQ - HiveMQ CE - VerneMQ - EMQ X
- Mosquitto outperforms the other considered solutions in most metrics;
- ActiveMQ is the best performing one in terms of Scalability due to its multi-threaded implementation.
- Bevywise MQTT Route has promising results for resource-constrained scenarios.
- ActiveMQ scales well in distributed/multi-core environment to beat all other brokers’ performance.
- If the hardware is resource-constrained (CPU/Memory/IO/Performance), then Mosquitto or Bevywise MQTT Route can be taken as better choices.