Keep Alive, please don’t let your MQTT service become Peppa Pig!

Special people! Brother, sister, younger sister, uncle, aunt

Speak some gossip

Keep alive, not just for MQTT, but for many of our systems, when we need to determine whether the other party is communicating. For example, in audio chat, both sides and the server also need a set of keep alive mechanism to determine the status of both sides for corresponding processing.

Understanding Keep Alive is instructive for system design.

MQTT’s Keep Alive mechanism

Why is it necessary to keep alive?

TCP half-open connection problem half-open.

First, MQTT is based on TCP, so TCP features also apply to MQTT: reliability, order, error detection.

However, the transmissions between communication parties using a TCP connection are sometimes not synchronized.

For example, if one party crashes or a transfer error occurs during communication, the incomplete connection state is called “half-open”.

The problem then is that the communication parties, one party crash does not notify the other party, then the party still connected will continue to request and wait for a reply. This is obviously a bad experience for the person who is still connected, or it doesn’t make sense.

Andy Stanford-Clark, the inventor of MQTT, explains this.

Further to the specification, the purpose of KeepAlive is to let the application level (client applications and agents) know that the underlying connection is still end-to-end.

Although TCP/IP theoretically notifies you when a socket is down, in practice, especially in cases such as mobile and satellite links, it is common to “fake” TCP in the air and put the header back on each end, it is highly likely that the TCP session will end up in a “black hole” where it still appears to be open, But really just dump whatever you’ve written on the floor.

Therefore, Keepalive will confirm that you are indeed still talking to the proxy (and from the proxy, the client is indeed still connected), especially if you are on a long-running connection, or subscribed to infrequently published topics, or published to the Borker proxy at QOS0 (that is, without confirmation).

Ping-resp (” pong “!) of the “ping-req” started by the response client returned from the broker should be used (by the MQTT library). To tell the application whether the connection has disappeared or to trigger a reconnect.

MQTT then includes such a “keepalive” feature that provides a solution to the half-open problem, or a basis for evaluating whether a connection is broken.

Keep Alive confirms that the connection between the broker and client is still open and that the broker and client are aware of being connected to each other

The operation is that the client communicates with the server every second after the connection is established. This interval defines the maximum length of time that the client and the server do not communicate.

MQTT defines it as follows:

“The Keep Alive … is the maximum time interval that is 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.”

That is, keep Alive is the maximum interval between the time when the client finishes sending packets and the time when the next packet is sent. It is the client’s responsibility to send PINGREQ packets accurately.

As long as messages are exchanged frequently and within the time frame defined by Keep Alive, there is no need to send additional messages to confirm the connection.

But if, in the meantime, the client does not send a message, it must send a PINGREQ packet to confirm that both the client and the agent are available.

The agent disconnects the client if it does not receive any messages or PINGREQ packets from the client within the 1.5x Keep Alive interval. Similarly, the client should close the connection if it does not receive a response from the proxy within a reasonable time.

Keep Alive Flow

The Keep Alive function uses two packets to ensure this: PINGREQ and PINGRESP

PINGREQ is sent by the client with no payload, and the client can send this packet at any time to confirm the connection status.

When a server receives a PINGREQ packet, it must reply with a PINGRESP packet to indicate that it is still available, and the same PINGRESP packet does not contain a payload

Something you have to know

  • If the client does not send any packets or PINGREQ to the server agent during the keep Alive period, the agent closes the connection and sends the last will message to LWT (if the client is set).
  • It is the responsibility of the MQTT client to set the appropriate Keep Alive value. For example, the keep Alive interval can be adjusted according to the current signal strength.
  • The maximum keep alive interval is 18h 12min 15 SEC. If the keep alive interval is 0, the Keep alive mechanism is invalid.

Client task-over Indicates that the Client takes Over control

Typically, a client may reconnect after disconnecting. Sometimes the broker server will still provide a half-open connection to the client (for example, during the 1.5-fold Keep Alive interval when the client tries to disconnect and reconnect, there will be two client connections). In MQTT, if the broker agent detects a half-open connection, Client takeover is performed, and Borker disconnects the previous connection and establishes a new connection with the client. This behavior ensures that the half-open connection does not prevent the client from disconnecting and reconnecting.