Here are reported the MQTT best practices you can follow to optimize the network traffic and prevent data loss.

Network traffic optimization

Keep-alive interval

MQTT libraries generally use the keep-alive-interval to generate a periodic PING telling the server the client is still alive.

A wrong keep-alive-interval may generate a waste of bandwidth, to prevent this, it should be sized according to the publishing frequency.

Generally, this value is set to a value double than the average time between consecutive messages. 

In case the LWT has been configured, and if the client uses a keep-alive-interval of 5 minutes, Servitly will recognize the product is OFFLINE only after 5 minutes than the last received message.

Deferred publishing

Another way to optimize the network traffic is to collect messages locally into the device, and publish them in a single connection session opened periodically (e.g. every hour). Note that in this case, measures are not in real-time. To mitigate this, you can decide to publish in real-time only the important data, like alerts.

Metric data aggregation

If you need to send multiple metrics (with the same metric path), it is suggested to group them all into a single message. Moreover, if a metric does not change so often, you can decide to publish it only when its value changes.

Data Loss Prevention

It could happen that the MQTT broker maybe not be reachable for a limited time, and this can occur when:

• The thing is offline (e.g. no GSM/Wi-Fi coverage)

• There is a problem on the network where the thing is connected (e.g. Wi-Fi without Internet access).

• The MQTT broker service is rebooted for planned maintenance (e.g. new release, certificate update) or unplanned maintenance (e.g. security fix).

• The MQTT broker is down due to unexpected problems.

For these reasons, to create a robust system without any data loss, the MQTT client running on the things must:

• At least use a QoS (Quality of Service) equals 1, allowing the thing to acknowledge the message has been received.

• Automatically reconnect to the broker when a connection problem occurs. This can be done through the underlying MQTT library which should support the auto-reconnect or allow listening on connection events (e.g. onConnect, onDisconnect) and react on them.

• During the OFFLINE period, locally store unpublished date, this generally is automatically performed by the underlying MQTT library, for instance, PAHO supports an in-memory or disk persistence. Data are stored on the client-side while OFFLINE, and then bulk published when the client turns back ONLINE.

Certificate Management

Always remember, that to open the connection your client must have the Servitly CA installed and up-to-date. For more details refer to the SSL Certificates article.