keep alive mqtt option

[gauthamkantharaju]

Hi,

Using aws-iot-device-sdk npm package (version 2.2.1) for publishing data to cloud. NodeJS application (mqtt client) code publishes data to cloud.

device = awsIot.device({
            keyPath: process.env.AWS_MQTT_KEY,
            certPath: process.env.AWS_MQTT_CERT,
            caPath: process.env.AWS_MQTT_ROOTCA,
            clientId: process.env.AWS_MQTT_CLIENT_ID,
            region: process.env.AWS_MQTT_REGION,
            host: process.env.AWS_MQTT_HOST,
            offlineQueueMaxSize: parseInt(process.env.AWS_MQTT_OFFLINE_QUEUE_MAX_SIZE),
            offlineQueueDropBehavior: process.env.AWS_MQTT_OFFLINE_QUEUE_DROP_BEHAVIOR,
            maximumReconnectTimeMs: parseInt(process.env.AWS_MQTT_MAX_RECONNECT_TIME_MSEC),
            keepalive: parseInt(process.env.AWS_MQTT_KEEPALIVE_SEC)
        });

1) Disabled keepalive option (keepalive = 0, ping disabled), so as per the AWS IoT documentation (https://docs.aws.amazon.com/general/latest/gr/aws_service_limits.html#limits_iot )

" For MQTT (or MQTT over WebSockets) connections, a client can request a keep-alive interval between 30 - 1200 seconds as part of the MQTT CONNECT message. AWS IoT starts the keep-alive timer for a client when sending CONNACK in response to the CONNECT message. This timer is reset whenever AWS IoT receives a PUBLISH, SUBSCRIBE, PING, or PUBACK message from the client. AWS IoT will disconnect a client whose keep-alive timer has reached 1.5x the specified keep-alive interval (i.e., by a factor of 1.5).The default keep-alive interval is 1200 seconds. If a client requests a keep-alive interval of zero, the default keep-alive interval will be used. If a client requests a keep-alive interval greater than 1200 seconds, the default keep-alive interval will be used. If a client requests a keep-alive interval shorter than 30 seconds but greater than zero, the server treats the client as though it requested a keep-alive interval of 30 seconds. "

default keepalive interval i.e. 1200 seconds should be used and after every publish the timer resets right?

NodeJS application (mqtt client) publishes data every 5 minutes for the first 5 times and after that publishes data every 15 minutes but first 5 published was successful, after that even though application was publishing data never reached to cloud (AWS IoT). I think AWS IoT timer was never reset because there was no two way data flow (MQTT client <-> AWS IoT)? else let us know what the issue is?

2) When keepalive is enabled (for ex: keepalive = 300 seconds) then NodeJS application publishes data without any issues because mqtt client send ping requests and receives ping response from the AWS IoT (broker), correct?

Looking forward to hearing from you soon!!

Thanks in advance, Gautham

[gauthamkantharaju]

Can the keep alive mqtt option be disabled? if not, may I know the reason?

Reason for disabling keep alive mqtt option is because we will be publishing data at regular intervals so we don't need ping requests and responses between client and mqtt broker.

[justinboswell]

NodeJS application (mqtt client) publishes data every 5 minutes for the first 5 times and after that publishes data every 15 minutes but first 5 published was successful, after that even though application was publishing data never reached to cloud (AWS IoT).

So in this instance, you've disabled keepalive (if I'm reading your post right). If that's the case, then you've been disconnected and did not reconnect, so it makes sense that your messages would not reach the service.

Can the keep alive mqtt option be disabled? if not, may I know the reason?

You can disable it by setting it to 0, however, if you do not send messages every now and then, you may well see the connection drop and/or see your will message published. The main reason it is there is to indicate to the service that your client is still there, and that its will should not be published.

[gauthamkantharaju]

So in this instance, you've disabled keepalive (if I'm reading your post right). If that's the case, then you've been disconnected and did not reconnect, so it makes sense that your messages would not reach the service.

If that's the case, mqtt client should automatically retry to establish connection and subsequent messages should be published to service? but in my case after first 5 publish, subsequent publishes are lost and never reach the service unless the application is restarted enabling keep alive option (for ex: keepalive = 300).

[gauthamkantharaju]

Did test disabling keep alive option (keepalive = 0), as said in the previous comments, first 5 message did reach the service without any issues but right after the subsequent message were published from NodeJS application, below mqtt events were seen,

MQTT client went offline DNS issue or AWS IoT sdk error: Error: read ECONNRESET MQTT client disconnected MQTT client reconnecting Connected to MQTT Server

and most importantly message published did not reach the service. Is NodeJS application (mqtt client) is not getting connected to broker/service at all?

[justinboswell]

What are the values of your offlineQueueMaxSize and offlineQueueDropBehavior? The sample code in the original post only points at environment variables.

Also, once you're disconnected and reconnected, step through your next publish() call and see which branch it takes, and see if it ends up queueing the message because there are messages in the queue already.

[gauthamkantharaju]

AWS_MQTT_OFFLINE_QUEUE_MAX_SIZE = 8640 AWS_MQTT_OFFLINE_QUEUE_DROP_BEHAVIOR = newest

One more observation,

If keep alive set to a value greater than default AWS IoT interval (1200), see the same ECONNRESET issue after 30 minutes (1200 * 1.5 = 1800 seconds).

I guess AWS IoT (broker) has some issues when default keep alive (1200) value is used.

[ColdenCullen]

As mentioned in the page you linked above, IoT Core's valid range for keep alive times is 30-1200 seconds. Using anything outside of that range (including 0) is unsupported.

[gauthamkantharaju]

The default keep-alive interval is 1200 seconds. If a client requests a keep-alive interval of zero, the default keep-alive interval will be used.

Then above statement is from the same link, is it incorrect?

I did test keepalive with '0' with a stable ethernet connection and surprisingly it did work without any issues!! but same test on an unstable connection (cellular network) did not work, approx after 30 minutes with ECONNRESET issue and was not able to publish data to service thereafter.

[ColdenCullen]

It's possible some behavior will be subtly different when using 0 vs 1200. If 1200 works for you, I'd suggest just sticking with that.

[gauthamkantharaju]

Oh ok, that's what I thought. Thanks for the responses, appreciated!!

[ColdenCullen]

Happy to help 👍