What happens when network disconnects abruptly?

[shekharhimanshu]

Hello,

Could you please explain how does the SDK behave on abrupt network disconnect?
When auto-reconnect is enabled, will the SDK be able to recover automatically as in be able to mqtt publish/subscribe/unsubscribe without connecting manually?

Will the disconnect callback be called in such abrupt network disconnect events?

Thanks

[vareddy-zz]

Hi @shekharhimanshu ,
On abrupt disconnect, the keep-alive ping request will fail and trigger the auto-reconnect procedure. On successful reconnect, the device will resubscribe to the topics which it had subscribed to on first connection.

The relevant keep-alive code can be found here

I'm not sure if I understand what you mean by publish/subscribe/unsubscribe. If you continue publishing on a disconnect, those publishes will fail until the device reconnects. After the auto-reconnect is successful, all MQTT operations will work as before.

And yes, the disconnect callback will be called in such cases.

You will see a delay between when the actual disconnect happens and when the callback is called/auto-reconnect process starts as the keep-alive needs to fail before it can recognize the fact that it is disconnected. The keep-alive interval can be changed in the config.json that is used by the project here.

Please keep us posted if you have any more questions.
Thanks!
Varun

[shekharhimanshu]

Hello @vareddy

This clears most of my doubts. Thanks!

[shekharhimanshu]

Hello,

After looking through more code, I have one more think to confirm.
During abrupt disconnect, the SDK has no way to know the disconnect event. As a result of which, previously subscribed subscriptions will remain active. (Please correct me if I am wrong here)
Now since AWS IoT message broker does not support persistent sessions at the moment (source here), applications must connect & re-subscribe themselves. (if applications want to handle abrupt disconnect themselves and not wait for the next PING request to fail).
However, when subscribing, the code here removes active subscriptions from the subscribe request packet which means connect -> subscribe -> abrupt disconnect -> connect -> subscribe sequence will not succeed.

The workaround here is to unsubscribe before subscribing again. The unsubscribe here will have no meaning to the AWS IoT message broker and will only clean up the SDK internal state.
I wanted to confirm if this is the correct behavior?

[chaurah]

Hi @shekharhimanshu,
That is not supposed to happen and is a bug. I think this warrants a second look at the overall subscription flow in the SDK. Maybe a central API for managing all subscriptions that the client(s) talk to? I will give this some thought and see if I have an easy solution for you while we work on this. It should be as simple as setting all subscriptions to inactive in the current flow but I don't know if that makes sense in the longer term.

Please let me know if you have further suggestions.

Rahul

[shekharhimanshu]

Thank you for the confirmation.

I think this warrants a second look at the overall subscription flow in the SDK.

IMHO, the SDK needs to define what spec of MQTT it is following as the base specification.
Whether the one defined by AWS Iot message broker here or the standard MQTT version 3.1.1.

AWS Iot message broker says Although the AWS IoT message broker implementation is based on MQTT version 3.1.1, it deviates from the specification as follows: ....

If the SDK strictly follows AWS Iot message broker specifications, it should clean the subscriptions on each disconnect -> connect event since AWS Iot message broker does not support persistent sessions at the moment and should change the specification when AWS Iot message broker supports it.

For me, the workaround of connect -> subscribe -> abrupt disconnect -> connect -> **unsubscribe** -> subscribe works at the moment (although I don't like the unnecessary unsubscribe call) but in the long term, the SDK should have a clear specification about subscriptions management.

It might be helpful to see how other mqtt clients like Mosquitto handle these situations (given the SDK follows the standard MQTT version 3.1.1).

[chaurah]

Hi @shekharhimanshu,
You are correct ofcourse. The SDK should be following the AWS IoT message broker implementation and not the exact MQTT v3.1.1 standard. I will make a note to go through the SDK APIs once more to ensure we are not breaking that in any other areas. Please do let me know if you find any such issues.
Thank you for the great contributions as always :)

Rahul

[shekharhimanshu]

Clear explanation/notes about these things inside the api reference/document is highly appreciated as well.

[vareddy-zz]

Hi @shekharhimanshu,
v1.1.1 now takes care of subscription cleanup on disconnect.
Thanks!
Varun