HiveMQ Logo
What Is MQTT Keep Alive and Client Take-Over? – MQTT Essentials Part 10

What Is MQTT Keep Alive and Client Take-Over? – MQTT Essentials Part 10

author HiveMQ Team

Written by HiveMQ Team

Category: MQTT Essentials MQTT

Published: March 16, 2015

Updated: June 27, 2023

Keep Alive is a feature of the MQTT protocol that allows an MQTT client to maintain its connection with a broker by sending regular control packets called PINGREQ to the broker. Here’s Part 10 of MQTT Essentials, a ten-part blog series on the core features and concepts of the MQTT protocol, where we focus on Keep Alive feature of MQTT. If you are looking to understand what is MQTT Last Will and Testament (LWT), check out Part 9 of this series. Else, let’s dive into MQTT Keep Alive’s critical role in mobile networks, and in maintaining a robust and efficient MQTT connection.

Table of Contents

What is MQTT Keep Alive and Why It’s Important?

The Keep Alive mechanism in MQTT ensures the connection’s liveliness and provides a way for the broker to detect if a client becomes unresponsive or disconnected.

Learn about MQTT Protocol

Get the MQTT Essentials eBook

72 pages of MQTT education and learning for beginners and experts alike.

When a client establishes a connection with an MQTT broker, it negotiates a Keep Alive value, which is a time interval expressed in seconds. The client must send a PINGREQ packet to the broker at least once within this interval to indicate its presence and keep the connection alive. Upon receiving a PINGREQ packet, the broker responds with a PINGRESP packet, confirming that the connection is still active.

The MQTT Keep Alive mechanism is important for connection monitoring, efficient resource utilization, detecting network failures, graceful disconnection, etc.

Now, let’s establish why the kept alive feature is so important by delving into the issue of half-open TCP connections and how it poses a challenge within MQTT, particularly in mobile networks.

The Problem of Half-Open TCP Connections in MQTT

The problem of half-open TCP connections arises within [MQTT, which relies on the Transmission Control Protocol (TCP)(/blog/mqtt-essentials-part-3-client-broker-connection-establishment/) to ensure “reliable, ordered, and error-checked” packet transfer over the internet. Despite TCP’s robustness, there are instances where the synchronization between communicating parties can falter due to crashes or transmission errors.

In TCP, this state of an incomplete connection is referred to as a half-open connection, where one side of the communication remains unaware of the other side’s failure. The connected side persistently attempts to send messages while eagerly awaiting acknowledgments.

Core features and concepts of the MQTT protocol, including Keep Alive, explained.

Andy Stanford-Clark, the inventor of the MQTT protocol, highlights that the issue of half-open connections becomes more pronounced in mobile networks. While TCP/IP theoretically notifies users when a socket breaks, practical scenarios, particularly on mobile and satellite links, involve the “faking” of TCP over the air with added headers at each end. This practice can lead to a phenomenon known as a “black hole” TCP session, where the connection appears open but, in reality, discards any transmitted data.

"Although TCP/IP, in theory, notifies you when a socket breaks, in practice, particularly on things like mobile and satellite links, which often “fake” TCP over the air and put headers back on at each end, it’s quite possible for a TCP session to “black hole,” i.e. it appears to be open still, but is just dumping anything you write to it onto the floor."

Andy Stanford-Clark on the topic "Why is the keep-alive needed?" Source

How Does MQTT Keep Alive Work?

To address the challenge of half-open connections and enable continuous assessment of connection status, MQTT incorporates a vital feature called Keep Alive. This mechanism guarantees that the connection between the MQTT broker and client remains active and that both parties know their connection status.

When a client establishes a connection with the broker, it specifies a time interval in seconds known as the Keep Alive duration. This duration sets the maximum allowed time gap during which the broker and client may not exchange any communication. According to the MQTT specification, the Keep Alive interval is defined as follows:

"The Keep Alive ... is the maximum time interval permitted to elapse between the point at which the Client finishes transmitting one Control Packet and the point it starts sending the next. It is the responsibility of the Client to ensure that the interval between Control Packets being sent does not exceed the Keep Alive value. In the absence of sending any other Control Packets, the Client MUST send a PINGREQ Packet."

As long as messages are transmitted frequently within the Keep Alive interval, there is no need to send an additional message to verify the connection status. However, if the client remains inactive during the Keep Alive period, it must send a PINGREQ packet to the broker as a confirmation of its availability and to ensure that the broker is still accessible.

If a client fails to send any messages or a PINGREQ packet within one and a half times the Keep Alive interval, the broker is responsible for disconnecting the client. Likewise, the client should close the connection if it does not receive a response from the broker within a reasonable timeframe.

By employing the Keep Alive mechanism, MQTT enhances connection stability, mitigates the risks associated with half-open connections, and facilitates efficient communication between brokers and clients in various network conditions.

How Does Keep Alive Ensure Connection Vitality?

Let’s examine the flow of Keep Alive messages to gain a deeper understanding of the Keep Alive mechanism. The Keep Alive feature utilizes two packets: PINGREQ and PINGRESP.

What is PINGREQ in MQTT Keep Alive?

pingreq in MQTT

When a client wants to signal its continued presence and activity to the broker, it sends a PINGREQ packet. This packet is a “heartbeat” message indicating that the client is still alive. If the client has not sent any other type of packet, such as a PUBLISH or SUBSCRIBE packet, it must send a PINGREQ packet to the broker. The client can choose to send a PINGREQ packet at any time to verify the ongoing vitality of the network connection. Notably, the PINGREQ packet does not contain any payload.

What is PINGRESP in MQTT Keep Alive?

pingresp in MQTT

Upon receiving a PINGREQ packet from a client, the broker is obligated to respond with a PINGRESP packet. The PINGRESP packet serves as an acknowledgment from the broker to the client, confirming its availability and continued connection. Like the PINGREQ packet, the PINGRESP packet does not include a payload.

How Can I Customize Keep Alive Settings for Optimal Performance?

  • If the broker does not receive a PINGREQ packet or any other packet from a client within the expected time frame, the broker will close the connection and dispatch the last will and testament message(LWT) message if the client has specified one.
  • The MQTT client is responsible for setting an appropriate keep alive value. For instance, the client can adjust the keep-alive interval based on its current signal strength, optimizing the connection for its specific circumstances.I.
  • Importantly, the maximum Keep Alive interval is 18 hours, 12 minutes, and 15 seconds. Conversely, setting the Keep Alive interval to 0 effectively deactivates the Keep Alive mechanism, removing its influence on the connection’s stability and management.

What is Client Take-Over in MQTT?

In the MQTT protocol, when a client becomes disconnected, it typically attempts to reconnect. However, there are instances when the broker still maintains a half-open connection for that client. In such cases, when a client, which the MQTT broker perceives as online, initiates a reconnection and performs a `client take-over, the broker takes necessary action. It promptly terminates the previous connection associated with the same client (identified by the client identifier) and establishes a fresh connection with the client. This intelligent behavior ensures that half-open connections do not impede the disconnected client from successfully re-establishing its connection. By seamlessly managing client take-over, MQTT guarantees smooth connectivity and resilient communication in the face of intermittent network interruptions.

Conclusion: Keep Alive and Client Take-Over Enhancing MQTT Performance

The keep alive feature and client take-over mechanism are vital components of MQTT that ensure reliable and efficient communication in various scenarios. By implementing Keep Alive messages through PINGREQ and PINGRESP packets, MQTT enables clients to actively signal their presence and verify network connectivity. This mechanism prevents half-open connections and allows for timely detection of inactive or lost connections.

Furthermore, client take-over facilitates seamless reconnection for disconnected clients. When a client initiates a reconnection, the MQTT broker intelligently closes any existing half-open connection associated with that client and establishes a fresh connection. This process ensures that disconnections do not hinder the client’s ability to regain connectivity and resume communication smoothly.

MQTT clients must set appropriate keep alive values, considering factors such as signal strength and network conditions. This allows for optimal management of the keep alive mechanism and ensures efficient resource utilization.

Understanding the intricacies of the keep alive feature and client take-over in MQTT empowers developers to build robust and resilient MQTT applications. By leveraging these capabilities, MQTT facilitates the creation of reliable, real-time IoT and messaging solutions that thrive even in challenging network environments.

Watch the video below that complements the concepts discussed in this article.

Congratulations on completing Part 10 of our MQTT Essentials series! We hope you have found the entire series informative and engaging. While this marks the end of the official MQTT Essentials Series, we have an exciting MQTT Essential special edition focusing on MQTT over Websockets, which delves deeper into integrating MQTT with web applications and expand your MQTT knowledge even further.

Want to revisit any topics in the series? Visit the home of our MQTT Essentials Guides. You can also advance your knowledge in MQTT with our MQTT 5 Essentials series.

Thank you for joining us on this MQTT journey, and we look forward to continuing to provide valuable insights and resources in the world of MQTT.

FAQs on MQTT Keep Alive and Client Take-Over

The maximum Keep Alive interval is 18 hours, 12 minutes, and 15 seconds. However, a long Keep Alive interval might not be practical in many situations.

If the interval is too long, it will take more time for the broker to recognize that the client has disconnected in the case of network failure or any other issues.This could delay the sending of LWT messages, and it could also mean that the broker maintains the client's session for a longer time than necessary, potentially consuming unnecessary resources.

Yes, you can disable the MQTT Keep Alive functionality, although it's not typically recommended.

When an MQTT client wants to take over an existing session, it sends a CONNECT message to the broker. In the CONNECT message, it includes the same ClientID that was used for the existing session.

Yes, there are several strategies that can be used to prevent unintended client takeovers in an MQTT system. This includes using unique ClientIds, strong authentication and authorization mechanisms, and application level measures etc.

When a client takes over an existing session by using the same Client Identifier (ClientID) and setting the "clean session" flag to 0 during connection, the broker resumes the session, including any pending Quality of Service (QoS) 1 or 2 messages.

When a client tries to connect with a different ClientID than the one used for an existing session, the broker treats this as a new connection request from a completely different client. The broker will start a new session for this client and any subscriptions or messages associated with the previous ClientID won't affect this new session.

author HiveMQ Team

About HiveMQ Team

We love writing about MQTT, IoT protocols and architecture in general. Our experts are here to help, so reach out to us if we can help!

mail icon Contact HiveMQ
newer posts MQTT over WebSockets - MQTT Essentials Special
What is MQTT Last Will and Testament (LWT)? – MQTT Essentials: Part 9 older posts