You are viewing an old version of this page. View the current version.

Compare with Current View Page History

Version 1 Next »

When Store and Forward is enabled and the edge node detects a disconnect to the MQTT Server, tags will be stored locally in a history store.

How quickly the edge node detects the disconnect and starts to store the data will minimize the data loss when using MQTT Store and Forward and there are a couple of configuration parameters that can assist with this. 

MQTT Transmission Keep Alive

The MQTT protocol is hosted on top of the TCP protocol, which is connection-oriented, and provides a stable and orderly flow of bytes between two connected parties. Normally when the MQTT Transmission client attempts to send data over TCP, it will receive an error at the TCP level if disconnected and can immediately start to buffer data locally.

However, in some cases, TCP can have half-connection problems. A half-connection is a connection that has been disconnected or not established on one side, while the connection on the other side is still maintained. In this case, the half-connected party may continuously send data, which obviously never reaches the other side. To avoid black holes in communication caused by half-connections, the MQTT protocol provides a Keep Alive mechanism that allows the client and MQTT server to determine whether there is a half-connection problem, and close the corresponding connection.

For MQTT Transmission the Keep Alive is the maximum interval in seconds between any two MQTT protocol control packets sent by the MQTT Transmission client to the data. If the client is idle and has no control packets to send, it will send PINGREQ protocol packets and expects to receive PINGRESP packets from the server. If no PINGRESP is received within 1.5 times the Keep Alive interval, the client will close the connection.

This means that, depending on the TCP connection failure, it can take up to 1.5 times the Keep Alive interval for MQTT Transmission to determine that it is disconnected and start to buffer data locally at the Edge and during this time data will be lost. 

For example, a Keep Alive of 30 seconds could result in up to 45 seconds of data loss in the event of a TCP half-connection scenario. Reducing the Keep Alive to 5 seconds would corresponding lower the the potential data loss to 8 seconds.

Setting the Keep Alive to a short interval will increase the data traffic over the TCP connection in the event that the client is idle.

Setting the Keep Alive to 0 will disable the Keep Alive functionality

Primary Host

  • No labels