“One of the problems we experienced was long latency when sending a message. The method we were using to send was reliable but slow, and there were limitations on how much we could improve it. With just a few weeks until launch, we ended up building a new mechanism that maintains a persistent connection to our servers. To do this without killing battery life, we used a protocol called MQTT that we had experimented with in Beluga”
MQTT is a lightweight messaging protocol which can be used to publish/subscribe messages. It provides transportation of messages with great speed and low bandwidth. That is why it is widely used in mobile application and IoT developments. Imagine how quick the IoT stream from the physical sensors should travel through the internet to reach the destination. Without having a delay of 20ms or less will not make sense. Here, MQTT comes to rescue. There are couple more things to learn first. The Broker, Topic, Clients and the QoS.
The Broker acts as the intermediary between the MQTT clients. It only forwards the message to the particular topic which the sender has included in the packet. It does not store any messages. But the broker can be connected to a particular function/program to trigger a storing or data manipulation. ALWAYS the message first sent to the BROKER.
A Client is someone who sends/subscribed to Topics. It is the receiving and sending end of the MQTT communication. Between two Clients, there is always a Broker. Eg: IoT devices.
The MQTT Topic is the address which the client sends the data to. And the clients will also subscribes to particular topics. Once the broker captures the message, it will get redirected to the afore declared topic. The Topic should not be declared in the Broker first. Clients could define their own Topics upon transmitting/subscribing, There are no limitations for Topics. A sample Topic will look like this “terminal1/application21/temperature”. A client can subscribed to this Topic and if anyone sends data to the particular Topic, all the subscribers of that Topic will receive the message as soon as it forwards by the Broker. Subscribing to the “terminal1” will not receive the messages which sends to the “terminal1/application21” and vice versa. And using wildcards (‘#’) it is easy to subscribe to any topic which goes after the ‘#’ character.
Eg: Subscribing to the “terminal1/#” will receive ANY message which will receive by “terminal/” , “terminal/application21/” and “terminal1/application21/temperature“. If anyone subscribed to “#”, they will get all the messages which is received to the MQTT Broker.
By using single level wildcards (‘+’), anyone can get messages above the declared level. Eg: Subscribing to the “terminal1/+/temperature” will receive the messages sent to the “terminal1/application1/temperature” and “terminal1/application21/temperature”.
QoS means Quality of Service. A QoS level is responsible for the speed and the reliability of the sending/receiving data. There are three QoS levels. QoS 0 is the fastest of all. If the Client sends the data with QoS 0, the receiving-end will get the message as soon as possible. It is because, the Sender will not get a feedback whether the data has been successfully received on the other end. It will just fire and forgets. By using the QoS 1, it has the feedback functionality, which the sender will get to know if it has been successfully received by the other end. It will fire and look whether the bullet has been gone to the target. It provides reliability, but not the speed of QoS 0. QoS 3 is an advancement to the QoS 1 which can be used in extreme cases where MQTT will guarantee the delivery of the packet to the other end. However, it is rarely used. QoS level can be declared whenever the Client sends the message or subscribing to a Topic. Nevertheless, whatever the QoS level the Client subscribed to, if the Sending Client has wrapped a message in QoS lower than the receiving Client, It will act as the least level of two.
There are many third party MQTT clients available. Which can be used to act as a Client which sends the data to the Broker and subscribes to different Topics. The best client which I have used so far is the MQTT.fx. Which is free and easy to use and it supports for Windows, Linux and MacOS. I have used MQTT in Mobile Applications which will use secure connections using the TLS1.2 through the AWS (Apparently, the AWS will not provide the QoS level 3 data transmission). And it is best when used with QoS 0 where the IoT stream could be transmitted (Where the latency needs to be low as possible). And it is also used in Facebook Messenger.