In previous articles, we introduced the following topics in MQTT 5.0:Detailed Explanation of MQTT Packets【01】: CONNECT & CONNACKDetailed Explanation of MQTT Packets【02】: PUBLISH & PUBACKDetailed Explanation of MQTT Packets【03】: SUBSCRIBE & UNSUBSCRIBENow, we will introduce the control packets used to maintain the connection: PINGREQ and PINGRESP.
In addition to the control packets for connecting, publishing, and subscribing, MQTT also has a type of packet used to simulate a heartbeat between the client and server to maintain the connection. These are the PINGREQ and PINGRESP packets, which we commonly refer to as heartbeat packets.
The client periodically sends a PINGREQ packet to the server to let the server know that the connection is normal and that the client is still active. For each PINGREQ packet received, the server replies with a PINGRESP packet, allowing the client to also know that the connection is normal and that the server is still active.
Sample Packet
We use MQTTX CLI to establish a client connection to a public MQTT server. We do not publish messages or subscribe to topics, but in Wireshark, we can still see MQTT packets appearing regularly between the client and server. These packets are PINGREQ and PINGRESP.
We can also use a command to create a client connection with a Keep Alive of 5 seconds, which will allow us to see the client sending PINGREQ messages quickly.
We will find that PINGREQ and PINGRESP packets are always only 2 bytes in size, and their content seems to never change:
These two packet structures are also particularly simple.
PINGREQ & PINGRESP
Packet Structure
The only difference between PINGREQ and PINGRESP packets is the packet type field in the fixed header. The packet type for PINGREQ is 12 (0x0C), while the packet type for PINGRESP is 13 (0x0D).The value of the reserved length field following the PINGREQ and PINGRESP packets is always 0, because neither the PINGREQ nor PINGRESP packets contain variable headers or payloads.
This structure minimizes the size of PINGREQ and PINGRESP packets, so sending them does not consume too much bandwidth.
Frequently Asked Questions
Q: What is the maximum interval for MQTT Keep Alive?
A: The value of the keepalive parameter is an integer representing seconds. For example, <span>keepalive=300</span> means the client should send a message to the MQTT broker every 300 seconds, such as PUBLISH. After another 150 seconds, the broker will close the connection.The maximum value for the Keep Alive interval is 65535, which is 18 hours, 12 minutes, and 15 seconds.
Q: Can the MQTT Keep Alive interval be set to zero?
A:You can disable the MQTT Keep Alive mechanism by setting the interval to 0: <span>keepalive=0</span>.
Q: What is the default cycle for MQTT Keep Alive?
A: The default value varies depending on the MQTT client library you are using. For example, the Python MQTT client sets the default Keep Alive interval to 60 seconds. Similarly, the Eclipse Paho MQTT browser-based JavaScript client library does the same. The MQTT PubSubClient for Arduino sets the keepalive interval to a default of 15 seconds.
However, when establishing a connection between the broker and the client, you can set any other Keep Alive interval up to 65535.
Q: Can the MQTT Keep Alive intervals be different? Can they differ between the broker and the client?
A: The client determines the Keep Alive interval in the MQTT protocol when establishing the connection.For MQTT v.5.0 clients, there is also a reverse way to set the MQTT Keep Alive value from the broker to the client. The broker can tell the client what Keep Alive interval it should use. <span>max_keepalive</span> option allows the client to use a Keep Alive interval not greater than the specified value. However, for MQTT v.3.1 and v.3.1.1 clients, there is no such mechanism to specify what Keep Alive interval to use.
Conclusion
PINGREQ and PINGRESP are the simplest packets in MQTT, and their content is fixed. The only thing we can change is the frequency at which the client sends PINGREQ packets by adjusting the Keep Alive option during connection.
The next two images are specific screenshots of the packets captured using Wireshark:
If the server does not receive any control packets from the client within 1.5 times the heartbeat keep-alive time, it will consider the client inactive or the network abnormal and disconnect. In the packet examples in this article, we set the heartbeat keep-alive to 5 seconds during connection, so the server’s timeout is 7.5 seconds.For the client, if it does not receive the PINGRESP packet from the server after sending the PINGREQ packet within a certain time, it should disconnect. This time length mainly depends on the client’s expected network latency and the specific implementation of each client SDK.
Reference Links:
-
https://cedalo.com/blog/mqtt-keep-alive-explained/
-
https://www.emqx.com/en/blog/mqtt-5-0-control-packets-04-pingreq-pingresp
- [Video Course] Codesys V3.5 Series Introduction Course(139 people have learned)
- [Video Course] Codesys SoftMotion Basic Course(42 people have learned)
- [Video Course] Codesys SoftMotion Electronic Gear Course(14 people have learned)
- [Video Course] Codesys SoftMotion Electronic Cam Course(9 people have learned)
- [Video Course] Making Custom Libraries in Codesys(23 people have learned)
-
Comprehensive Collection of Free Public Materials for Codesys V3.5 Series
-
Top Ten Common Filtering Algorithms (ST Language)
-
What Does a PLC Integrated with Chat GPT Look Like?
-
Sharing the Top 10 PLC Programming Books of 2023
-
Customize Your Own CODESYS Motion Controller
-
Can MC_Power.status = FALSE still allow the axis to move?
-
Collection of Learning Materials for ST Language
——–END——–
If you like this article, please share and “like” it below and “look” at it.