What Is MQTT Keepalive and the PINGREQ/PINGRESP Loop?

Back to Blog

What the Keepalive Interval Negotiates

The keepalive value is a 16-bit number of seconds the client places in its CONNECT packet, and it is a contract about the client's silence, not about traffic in general. It says: no matter what, I will not let this interval pass without sending the broker something. Any packet counts toward resetting the timer, so a client that is actively publishing telemetry may never need to send a dedicated ping at all. The ping only fills the gaps when the client would otherwise be idle.

The reason the mechanism exists is that a plain TCP connection can die silently. A cellular modem loses coverage, a carrier NAT table entry expires, or a firewall drops an idle flow, and neither end gets a clean FIN. Both sides believe the socket is open, a state often called a half-open connection. Keepalive gives the broker a deadline: if the promised traffic stops arriving, the connection is presumed dead regardless of what the TCP stack thinks. This is what makes the last will and testament reliable, because the will only fires when the broker declares the client dead.

A keepalive of zero disables the mechanism entirely, which is almost never what you want on a field link. With keepalive off, a modem that vanishes leaves a zombie session on the broker until the operating system's own TCP timeout eventually reaps it, which can be many minutes, and the will never fires promptly. For SCADA telemetry the whole point is fast, deterministic dead-node detection, so a nonzero keepalive is effectively mandatory.

How PINGREQ, PINGRESP, and the 1.5x Rule Work

When the client approaches the end of its keepalive interval with nothing to send, it emits a PINGREQ, a two-byte control packet with no payload. The broker answers with an equally minimal PINGRESP. That round trip proves both that the client is alive and that the path between them still carries traffic in both directions. The exchange is deliberately tiny because on a metered cellular plan every byte of overhead is a byte you pay for, a concern this page shares with protocol overhead in telemetry.

The broker's side of the deadline is defined as one and a half times the keepalive interval. If a client sets keepalive to 60 seconds, the broker waits up to 90 seconds of total silence before declaring it dead. That 1.5x grace exists so that a single slightly late ping, delayed by a congested link, does not trigger a false disconnect. The client, for its part, should send its ping comfortably before the interval expires, not at the last possible moment, so that a slow round trip still lands inside the window.

It is worth being precise about direction. Keepalive detects a client that has stopped talking to the broker; it is the client that must send PINGREQ. The broker does not ping the client. If you need the client to notice a dead broker quickly, that comes from the client's own read timeout and its expectation of receiving a PINGRESP, not from any broker-initiated probe. A client that sends a PINGREQ and never sees a PINGRESP within its own timeout should tear down the socket and reconnect, which ties into avoiding a reconnect loop.

Sizing Keepalive for a Cellular Telemetry Link

Choosing the interval is a trade between how fast you want to detect a dead node and how much idle traffic and battery you are willing to spend. A short keepalive, say 30 seconds, means the broker declares a lost RTU dead within about 45 seconds and the will fires quickly, which is good for alarming. The cost is a ping round trip every 30 seconds of idle time, which on a battery-powered site with a solar budget is a real load, and on a metered plan is a steady trickle of billable packets.

A long keepalive, several minutes, is gentle on the link and the battery but slow to notice a failure, so an operator may stare at a stale value for minutes before the point is flagged bad. There is also a hard ceiling imposed by the network you do not control: carrier NAT and firewall idle timeouts silently drop a flow that goes quiet for too long. If that timeout is, for example, four minutes, a keepalive longer than that guarantees the connection is killed by the network before your ping ever fires, and the client keeps reconnecting for no reason it can see.

The practical rule is to set keepalive shorter than the shortest idle timeout on the path, with margin, and no shorter than your dead-node detection requirement demands. On a well-behaved private APN you may run minutes; on public cellular through aggressive carrier NAT you often need to stay under a couple of minutes to hold the flow open. Because a cloud SCADA platform such as Merobix trends the connection state of every node, you can see which sites are flapping and tune keepalive per site rather than guessing one value for the whole fleet.

Frequently Asked Questions