MQTT keep-alive and timeout in IOT Protocols - Step-by-Step Execution

Process Flow - MQTT keep-alive and timeout

Client connects to Broker

↓

Client sends CONNECT with keep-alive

↓

Broker starts keep-alive timer

↓

Client sends PINGREQ before timer expires

↓

Broker receives PINGREQ and resets timer

↓

If no PINGREQ before timer expires

↓

Broker closes connection (timeout)

This flow shows how MQTT clients send a keep-alive value to the broker, which expects periodic PINGREQ messages to keep the connection alive. If the broker does not receive a PINGREQ in time, it closes the connection.

Execution Sample

IOT Protocols

CONNECT keep-alive=10s
---> Broker starts 10s timer
Client sends PINGREQ at 9s
---> Broker resets timer
Client sends PINGREQ at 19s
---> Broker resets timer
No PINGREQ by 29s
---> Broker disconnects client

This example shows a client connecting with a 10-second keep-alive, sending PINGREQ messages before the timer expires to keep the connection alive, and the broker disconnecting after a timeout.

Process Table

Step	Time (s)	Client Action	Broker Action	Timer State	Connection State
1	0	CONNECT with keep-alive=10	Start 10s timer	Timer set to 10s	Connected
2	9	Send PINGREQ	Receive PINGREQ, reset timer	Timer reset to 10s	Connected
3	19	Send PINGREQ	Receive PINGREQ, reset timer	Timer reset to 10s	Connected
4	29	No PINGREQ sent	Timer expired, disconnect client	Timer expired	Disconnected

💡 At 29s, no PINGREQ received before timer expired, so broker disconnects client

Status Tracker

Variable	Start	After Step 1	After Step 2	After Step 3	After Step 4
Timer (seconds left)	N/A	10	10	10	0 (expired)
Connection State	Disconnected	Connected	Connected	Connected	Disconnected

Key Moments - 3 Insights

Why does the broker disconnect the client at step 4?

Because the broker did not receive a PINGREQ before the 10-second timer expired, indicating the client might be offline or unreachable (see execution_table row 4).

What happens when the client sends a PINGREQ before the timer expires?

The broker resets the keep-alive timer to the full duration, keeping the connection alive (see execution_table rows 2 and 3).

Does the client have to send PINGREQ exactly at the timer expiration?

No, the client should send PINGREQ anytime before the timer expires to reset it; sending early is fine (see execution_table row 2 where PINGREQ is sent at 9s before 10s timer).

Visual Quiz - 3 Questions

Look at the execution_table, what is the connection state after step 3?

A Disconnected

B Connecting

C Connected

D Unknown

💡 Hint

Check the 'Connection State' column at step 3 in the execution_table.

At which step does the broker disconnect the client due to timeout?

A Step 2

B Step 4

C Step 3

D Step 1

💡 Hint

Look for the step where 'Timer expired' and 'Disconnected' appear in the execution_table.

If the client sends PINGREQ at 11 seconds instead of 9, what happens?

A Broker disconnects client at 10s

B Broker resets timer at 11s

C Connection stays alive without reset

D Client reconnects automatically

💡 Hint

Refer to the timer expiration logic in the execution_table and variable_tracker.

Concept Snapshot

MQTT keep-alive is a timer set by the client in CONNECT message.
Client must send PINGREQ before timer expires to keep connection alive.
Broker resets timer on PINGREQ receipt.
If timer expires without PINGREQ, broker disconnects client.
Keep-alive ensures broker detects lost clients quickly.

Full Transcript

MQTT uses a keep-alive timer to check if clients are still connected. When a client connects, it tells the broker how many seconds it will wait before sending a PINGREQ message. The broker starts a timer for this duration. The client must send a PINGREQ before the timer runs out. Each time the broker gets a PINGREQ, it resets the timer. If the timer expires without a PINGREQ, the broker assumes the client is gone and disconnects it. This process helps keep connections healthy and detect lost clients fast.