Do you know what Keep Alive in MQTT is and what it does? We’ll learn about MQTT’s Keep Alive implementation and why it’s essential in this blog. The keep alive feature, as its name suggests, is used to keep a network connection alive. This term isn’t just used in MQTT; it’s also used in a variety of other protocols. Keep alive ensures that the connection between a server and a client stays available and that both users are aware that they are connected. By guaranteeing that only one connection is used per client, network congestion and latency are reduced. This is especially useful in Machine-to-Machine interactions, because the nodes have very limited resources. This is why the Keep Alive feature is necessary in MQTT Broker client connection & communication.

 Keep Alive in MQTT

We already know that MQTT is built on the TCP/IP model, which assures that packets are exchanged in a reliable, orderly, and error-free manner. In fact, MQTT’s transport layer employs Transmission Control Protocol, which includes its own Keep Alive capability. Then you might wonder why there is a requirement for an additional maintain alive implementation on the Application layer. Even with the TCP stay alive implementation, in real-world applications, particularly in the case of IoT devices with so many limitations on the network, the transfer between communicating clients can become out of sync due to clients crashing, unreliable networks, or other issues. Furthermore, because MQTT is client-decoupled, if a connection is only half-open, the side that is still connected continues to transmit messages and waits for acknowledgements. 

How MQTT Keep Alive works

When the client connects to the broker, the client sends the broker a keep alive time interval in seconds. This interval specifies the maximum amount of time that the broker and the client may be unable to communicate with one another. There is no need to send an extra message to check if the connection is still open as long as messages are sent within the keep-alive period. If the client does not send a message during the keep-alive period, the broker must send a ping request packet to indicate that it is still reachable. The broker will respond to the client with a ping response packet, and the connection will be maintained. The keep alive timer is reset when the ping replies are received, and the cycle restarts. A client that does not send a message or a ping request packet in one and a half times the keep alive interval shall be disconnected by the broker. If the client does not get a ping response packet from the broker, the connection is expected to be closed. If the client has established a Last Will and Testament message, the LWT message will be forwarded to all subscribed clients during this disconnect.

Example

Here’s a simple example of how MQTT’s keep alive feature helps to keep network communication running smoothly. When particular circumstances, possibly related to temperature, are fulfilled, a sensor connected to the network is expected to send a message. The exact condition that causes the message to be sent cannot be measured, and it can happen at anytime. This sensor is beneficial for ensuring the safety of network-connected automated processes. Setting the keep alive interval to a low estimate ensures that the broker is always informed of the status of the client’s connection. A condition-driven message will be sent, or a steady flow of PINGREQ messages will verify that the client is connected. If the time interval is exceeded, the broker will terminate the connection and send the last will and testament message. This should contain warnings or alarms in the case of an essential network component like this sensor, so that preventative measures can be done.

Client Take-Over

Clients who have lost contact with their broker will, in most cases, try to reconnect. MQTT allows the broker to do a client take-over, which allows the broker to cancel a half-open connection and let the same client to establish a new connection. It’s a fail-safe to prevent devices from disconnecting from the network due to whatever condition triggered the half-open connection.  Allowing brokers to participate in client takeovers can be essential to maintaining communication in a MQTT network. The takeover ensures that the client’s ability to restore communication with the broker is unaffected by the difficulty that resulted in a half-open connection. It eliminates a potential point of failure in the network when clients are unable to terminate connections on their own.

Another reason MQTT is a great solution for current distributed networks and inter-device communication is its keep alive feature. You can design a robust network solution that can endure instances of unstable connectivity with adequate configuration.