Background
Keep alive is part of the variable header in the CONNECT message.
We have mentioned that the Broker needs to know whether the Client has disconnected abnormally to send the last will message. In fact, the Client also needs to quickly detect if it has lost the connection to the Broker in order to reconnect.
The MQTT protocol is an application layer protocol based on TCP. Theoretically, the TCP protocol notifies the upper layer applications when a connection is lost; however, TCP has a problem of half-open connections. I do not intend to analyze the TCP protocol in depth here, but it is important to remember that in this state, one end of the TCP connection has failed while the other end is unaware; it believes the connection is still open and takes a long time to realize that the connection has been lost. This situation is particularly common when using mobile or satellite networks.
Therefore, relying solely on the TCP layer’s connection status monitoring is insufficient. The MQTT protocol has designed a Keep Alive mechanism. Recall that when establishing a connection, we can pass a Keep Alive parameter, which is measured in seconds. The MQTT protocol stipulates: if the Broker does not receive any packets from the Client within 1.5 times the Keep Alive interval, the Broker considers the connection to the Client to be disconnected; similarly, if the Client does not receive any packets from the Broker, the Client considers the connection to the Broker to be disconnected.
MQTT also has a pair of PINGREQ/PINGRESP packets, which can be used to satisfy the Keep Alive agreement and detect connection status when there are no packets transmitted between the Broker and the Client.
For the Keep Alive mechanism, we also need to remember the following points:
-
If there has been packet transmission between the Client and Broker within a Keep Alive time interval, such as PUBLISH, the Client does not need to use PINGREQ; this is important when network resources are tight;
-
The Keep Alive value is specified by the Client, and different Clients can specify different values;
-
The maximum Keep Alive value is 18 hours, 12 minutes, and 15 seconds;
-
If the Keep Alive value is set to 0, it means that the Keep Alive mechanism is not used.
Note that if there are no other control packets to send, the Client must send a PINGREQ packet.
Regardless of the Keep Alive value, the Client can send a PINGREQ packet at any time and use the PINGRESP packet to determine the activity status of the network and server.
If the Keep Alive value is non-zero and the server does not receive a control packet from the Client within 1.5 times the Keep Alive time, it must disconnect the Client’s network connection, considering the network connection to be down.
After the Client sends a PINGREQ packet, if it does not receive a PINGRESP packet within a reasonable time, it should close the network connection to the server.
PINGREQ – Heartbeat Request Packet
When the Client has not sent any packets to the Broker within a Keep Alive time interval, such as PUBLISH and SUBSCRIBE, it should send a PINGREQ packet to the Broker.
The PINGREQ packet has no variable header and no payload, so the entire content of the PINGREQ packet (a total of 2 bytes) is: 0xc0 0x00
PINGRESP – Heartbeat Response Packet
When the Broker receives a PINGREQ packet from the Client, it should reply to the Client with a PINGRESP packet.
The PINGRESP packet has no variable header and no payload, so the entire content of the PINGRESP packet (a total of 2 bytes) is: 0xd0 0x00