1: Describes the MQTT protocol
Message Queuing Telemetry Transport (MQTT) is a lightweight, brokered “publish/subscribe” messaging protocol developed by IBM. It has the advantages of compact protocol, compact, strong expansibility and traffic saving. It can be extended on unreliable networks and is applicable to scenarios where hardware storage space or network bandwidth is limited. With the MQTT protocol, the sender and receiver of messages are not limited by time and space. The Iot platform supports device access using MQTT protocol.
Two: MQTT protocol main features
Use the publish/subscribe message pattern to provide one-to-many message publishing and decouple the application
2. Provide network connections using TCP/IP
3. There are three levels of QoS(Quality of Service) for message publishing.
-
“At most once” (Qos = 0), message publishing is completely dependent on the underlying TCP/IP network. Message loss or duplication may occur. This level can be used for environmental sensor data where it does not matter if the first read is lost because a second read will be sent shortly after.
-
“At least once” (Qos = 1) ensures that messages arrive, but message duplication may occur.
-
“Once only” (Qos = 2) ensures that the message arrives once. Message loss and duplication are unacceptable and there is additional overhead associated with using this quality of service level.
Three: the core role of the MQTT protocol
The MQTT protocol has three core roles: Publisher, Broker, proxy server, and Subscriber. The message publisher and subscriber are both Client roles, the message broker is a server, and the message publisher can be a subscriber at the same time. When a Client publishes a message on a topic, the Broker distributes the message to any Client that has subscribed to the topic.
MQTT server
The MQTT server is usually a server. It is the hub of MQTT information transmission and is responsible for passing the information sent by MQTT clients to MQTT clients. The MQTT server is also responsible for managing the MQTT client. Ensure smooth communication between clients and ensure that MQTT messages are correctly received and delivered.
The MQTT client
MQTT clients can publish information to and receive information from the server. When a client sends a message, we call it “Posting” the message. In order for the client to receive information from the server, it must first “subscribe” to the server. The operation of “subscribing” information is much like the official account we subscribe to in wechat. When the official account is updated, wechat will send a message to the users who have subscribed to the official account, telling them that an article has been updated.
An MQTT topic
When we just explained the MQTT client subscription information, we used the example of a user subscribes to an official account in wechat. In MQTT newsletters, the client is certainly not subscribed to by an official account, but by a “topic”. The MQTT server uses topics to control the MQTT communication.
Four: Connect the MQTT server
MQTT clients must go through MQTT servers in order to communicate. Therefore, whether an MQTT client publishes a message or subscribes to a message, it must first connect to an MQTT server. Let’s take a look at the details of the MQTT client connecting to the server.
First, the MQTT client will send a connection request to the server. The request is actually a packet containing connection request information. The official name of this packet isCONNECT 
These are the two steps the MQTT client takes to connect to the server. Next, let’s look at the contents of the CONNECT packet sent by the client when it connects to the server.
ClientId – ID of the client
ClientId is the id of the MQTT client. The MQTT server uses this identity to identify the client. So ClientId must be independent. If two MQTT clients use the same ClientId identity, the server will treat them as if they were the same client. Usually a ClientId is a string of characters
Username and password
The user name and password are used for authentication when the client connects to the server. Some MQTT servers require the client to provide a user name and password when connecting. You can connect to the server only after the client provides the correct user name and password. Otherwise, the server will deny the client connection, and the client will not be able to publish and subscribe to messages.
Username and Password are optional CONNECT information. In other words, some servers have client user password authentication enabled. Such servers can connect only when the client provides authentication information correctly. Of course, the client does not need to provide user name and password authentication information for those servers that do not have user password authentication enabled
CleanSession – To clear a conversation
To explain the specific meaning of cleanSession, it is necessary to begin with MQTT network environment. The connection between the MQTT client and the server may not be very stable, and it can be difficult to ensure that all information is transmitted accurately in an unstable network environment.
To ensure that important MQTT messages can be accurately received by the client. After the server sends a packet to the client, the client returns an acknowledgement packet to the server. If the server does not receive the acknowledgement packet returned by the client, the server will assume that the packet just sent to the client was not correctly delivered. In this case, the server will perform the following two operations:
1. Save the packets that have not been acknowledged by the client
2. Try to send the packet to the client again and wait for the acknowledgement message from the client again.
If cleanSession is set to “true”. The server does not require the client to acknowledge receipt of the packet and does not save any packet. In this case, even if the client misses the packet sent by the server, there is no way for the server to send the packet again. Conversely, if we set cleanSession to “false”. Then the server knows that in subsequent communications, the client may ask me to save messages that I did not receive.
KeepAlive – Indicates the heartbeat interval
While the MQTT server is running, when a client for some reason disconnects from the server, the server needs to know in real time. KeepAlive is used by the server to know the connection status of the client.
The client can periodically send a message to the server when it has no message to send to the server. This message for the heartbeat mechanism is also called a heartbeat request.
The purpose of the heartbeat request is to inform the server that the client is still online. Upon receiving the heartbeat request from the client, the server responds with a message. This reply message is called the heartbeat response.
During the heartbeat interval, if the client publishes a message, it will publish the message and not the heartbeat request. But during the heartbeat interval, if the client does not publish a message, it will publish a heartbeat request to the server. The purpose of this heartbeat request is to tell the server that I am still online.
SUBSCRIBE – SUBSCRIBE to the topic
When the client is connected to the server, it can publish messages as well as receive them. All MQTT messages have a topic. To receive a message, a client first subscribes to the topic of the message. In this way, when a client publishes a message to the topic, the client subscribing to the topic can receive the message.
To subscribe to a topic, the client first sends a topic subscription request to the server. The client implements this request by sending a SUBSCRIBE message to the server. Clients can also specify QoS when subscribing to topics. The server will provide the service guarantee according to the QoS in the SUBSCRIBE.