MQTT Persistent Session Subscription Loss After Network Disconnect/Reconnect

[shani-g-electreon]

Hi,

We are developing an IoT solution with the aws-iot-device-sdk-cpp-v2 library. Our devices run an Embedded Linux OS with a user-space application written in C++ (C runtime is uclibc, ARM CPU). This application links with the AWS SDKs (*.so libraris):

aws-iot-device-sdk-cpp-v2 (v1.31.0)
aws-crt-cpp (v0.25.0)
aws-sdk-cpp (v1.11.230)
aws-c-auth (v0.7.8)
aws-c-cal (v0.6.9)
aws-c-common (v0.9.10)
aws-c-compression (v0.2.17)
aws-c-event-stream (v0.3.2)
aws-c-http (v0.7.15)
aws-c-io (v0.13.36)
aws-c-iot (v0.1.18)
aws-c-mqtt (v0.10.0)
aws-c-s3 (v0.4.6)
aws-c-sdk-utils (v0.1.13)
aws-checksums (v0.1.17)
aws-lc (v1.19.0)

MQTT Configuration:

• Normal connection (TCP socket, port 8883)
• Clean Session: False
• Keep-Alive Interval: 5 sec
• QoS 0

My device subscribes to several topics (commands, desired properties, etc.) and publish to several topics (telemetry, reported properties, etc.)

In our architecture there are 3 types of time periods (that can be long, even days):

1. The device publishes messages and receives commands continuously.
2. The device does not publish messages (apart from keep-alive implemented in the SDK) and commands are not sent to it at all.
3. Times of disconnection from the network (depends on cellular communication).

I'm experiencing an issue with my MQTT connections, After a temporary network disconnect and subsequent reconnection, my client stops receiving messages on its subscribed topics, even though the connection is successfully re-established and the device can publish successfully and the device shadow shows that the device is connected to AWS IoT.

I would like to understand under what conditions AWS IOT Core server deletes a client's subscribed topics?
Is it required for that customer to subscribe again in certain situations? Is there another known issue around this?

Thanks,
Shani

[jmklix]

This sdk won't always resubscribe after a connections is reestablished. Yes, it is sometimes required that the customer subscribes again in certain situations. There are a few was you can handle this

• always resubscribe to every topic when you reconnect
• track which subscriptions are still connected and only resubscribe the other topic

[shani-g-electreon]

Thank you for your answer!

[bretambrose]

A few additional clarifications:

The SDK never resubscribes under any circumstances. If your session is still active on the broker then previously-established subscriptions will still be active. Whether or not a session was rejoined is communicated in the corresponding event:

311 client: https://github.com/awslabs/aws-crt-cpp/blob/v0.27.4/include/aws/crt/mqtt/MqttConnection.h#L60-L64
5 client: https://github.com/awslabs/aws-crt-cpp/blob/v0.27.4/include/aws/crt/mqtt/Mqtt5Client.h#L225-L231(you can check the connack packet's sessionPresent field, or you can check the negotiated settings rejoinedSession field)

If your session is not active then all subscriptions are gone and you must re-establish them. Blindly subscribing in all circumstances is the easiest way to handle this, at the cost of bandwidth. If you conditionally re-subscribe, you must track the state of each subscription individually, after all, you could have disconnected in the middle of subscribing -- you cannot assume that rejoining a session means all your expected subscriptions are live unless you know for certain that they were previously established successfully.

[shani-g-electreon]

Thank you for your answer, if I understand correctly, if I receive 'true' in one of the functions you mentioned, I can assume that the subscriptions that were previously successful are still saved.
How can I track the state of each subscription individually? is it just to check status in the initial subscribing or can I track it at any time?

[bretambrose]

Thank you for your answer, if I understand correctly, if I receive 'true' in one of the functions you mentioned, I can assume that the subscriptions that were previously successful are still saved. How can I track the state of each subscription individually? is it just to check status in the initial subscribing or can I track it at any time?

You'll need to check the result of individual subscribes and record/persist that state.

[shani-g-electreon]

Thank you!

[github-actions[bot]]

Hello! Reopening this discussion to make it searchable.