Ideal keepalive values / throttling possibilities?

[js1972]

I'm wondering if there is any guidance on the keepalive value.
What are the pros and cons to having it lower or higher.

I have had my app set to 60 for a long time now (and I don't know where I got that number from). It seems that the default is 1200.

I notice that sometimes I get a storm of messages (thousands per hour) due to connectivity issues. For example the other day I started getting the LWT sent from a disconnection continually about once per second for 15 minutes before I unplugged the device (which was the only way to recover).
So I'm trying to learn more about all the potential timeouts, etc and if there is a way to throttle the sending of messages/shadow updates.

Something that I am doing in my code which is probably bad is (potentially) sending messages/shadow updates when the device is disconnected. All these queued messages could be building up to a storm of messages...
Maybe my code should be checking "if disconnected" and block the sending of further shadow updates when in that state.

Any ideas?

[jmklix]

If you are seeing a lot of connectivity issues then you might want to increase your keepalive value. I'm not sure what would be best for your situation, but you could test a few different values including the 1200 default to see if that helps.

There is currently not a way to throttle sending messages/shadow updates, but it is something that we might add in the future. There are hard limits with the IoT core with how many messages can be sent.

You can keep sending messages while disconnected and the sdk will queue them. When you mentioned thousands of messages per hour, can you add more details about these messages? Are you receiving or sending them? What QOS are you using?

[js1972]

@jmklix it think its just my bad code that tends to create the "message storms" I mentioned. I can't really work it out - but some times when connectivity is flakey it goes haywire and sends thousands of messages and the fact that they are queues if QoS one only makes it worse I guess.
So throttling would be great to avoid bill-shock.
Ive' since changed my code a bit to avoid the possibility of even trying to send messages when connectivity has dropped and I haven't seen the issue occur again - but it as always intermittent and rare - so who know!!

You seem to be suggesting a higher keepalive value? As I mentioned above I have it set at 60 but looking through the source the default now seems to be 1200 so I'll change to that and see. Thankyou.

[jmklix]

I would suggest using the default keepalive to prevent message storms from happening. You can try different values, and see what works best for your use case.

[jmklix]

You can also try different methods to limit the amount to messages that you send. For example you can have your code only send a new publish if you subscribed to it and received it back. Please let us know if you are still having any problems with "message storms" while using this sdk

[github-actions[bot]]

Hello! Reopening this discussion to make it searchable.