MQTT Persistent Session Subscription Loss After Network Disconnect/Reconnect #740
-
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):
MQTT Configuration:
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):
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? Thanks, |
Beta Was this translation helpful? Give feedback.
Replies: 3 comments 4 replies
-
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
|
Beta Was this translation helpful? Give feedback.
-
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 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. |
Beta Was this translation helpful? Give feedback.
-
Hello! Reopening this discussion to make it searchable. |
Beta Was this translation helpful? Give feedback.
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-esta…