Add persistent storage for MQTT state #311
Conversation
Related to FreeRTOS#271 Add support for storing and restoring MQTT state in persistent memory to handle QoS2 messages after a device reboot. * Add function prototypes for `MQTT_SetOutgoingPublishRecord`, `MQTT_GetOutgoingPublishRecord`, and `MQTT_GetFailedPacketId` in `source/include/core_mqtt_state.h`. * Implement `MQTT_SetOutgoingPublishRecord`, `MQTT_GetOutgoingPublishRecord`, and `MQTT_GetFailedPacketId` functions in `source/core_mqtt_state.c`. * Update `README.md` to include instructions on using the new setter and getter functions. * Add unit tests for `MQTT_SetOutgoingPublishRecord`, `MQTT_GetOutgoingPublishRecord`, and `MQTT_GetFailedPacketId` functions in `test/unit-test/core_mqtt_state_utest.c`.
|
Hey, thanks for opening a PR! We recently landed having the library handle QoS1/2 re-transmits for the user to the main branch; this seems like its related. We should consider how these are used together The device could set its packet storage callbacks to use flash, though when initializing the library need to restore the in-transmit state as you have here. |
|
Hello @vishwamartur! Thank you for raising this PR. It seems quite useful. Let us take a look. We recently have added functionality for the library to be able to re-send publishes which were not ACKed before a disconnect and reconnect of MQTT connection with an unclean session. We will see whether this might be somehow linked with that feature. Thanks again for taking the time to create the PR! - Aniruddha |
|
|
||
| ### Setter Function | ||
|
|
||
| The `MQTT_SetOutgoingPublishRecord` function allows the application to set an outgoing publish record in the MQTT context. It can be used to restore the state of the MQTT context after a device reboot. |
There was a problem hiding this comment.
I wonder whether a callback might be more suitable here?
Here is what i am thinking: The method described here will work perfectly fine when the reboot is planned. But what if the reboot is unplanned such as a power failure or link to the internet goes down.
In such cases, application might not have enough time to ping the library repeatedly for new packets. I understand that there might be race condition even in callback. But it is less pronounced.
When the application calls the API described above, it can either do that very frequently leading to higher CPU consumption, or it can do that slowly leading to a higher chance of a missed QoS2 publish when a reboot happens.
|
Hi @AniruddhaKanhere and @archigup, Thank you for the feedback! I'm glad you see the potential of this feature. Regarding the callback suggestion, that's an interesting point. A callback approach would indeed reduce the risk of missing QoS2 messages, particularly in the case of unexpected reboots or network issues, where the application might not have enough time to poll for unacknowledged packets. I’ll explore implementing a callback mechanism to handle persistent storage updates, as this might provide a more robust solution for unplanned reboots. Additionally, I could look into ways to make the polling frequency adjustable to balance CPU usage and the likelihood of packet loss. Let me know if you have any specific requirements or additional insights on this. Thank you again for the thorough review and suggestions! Best regards, |
Related to #271
Add support for storing and restoring MQTT state in persistent memory to handle QoS2 messages after a device reboot.
MQTT_SetOutgoingPublishRecord,MQTT_GetOutgoingPublishRecord, andMQTT_GetFailedPacketIdinsource/include/core_mqtt_state.h.MQTT_SetOutgoingPublishRecord,MQTT_GetOutgoingPublishRecord, andMQTT_GetFailedPacketIdfunctions insource/core_mqtt_state.c.README.mdto include instructions on using the new setter and getter functions.MQTT_SetOutgoingPublishRecord,MQTT_GetOutgoingPublishRecord, andMQTT_GetFailedPacketIdfunctions intest/unit-test/core_mqtt_state_utest.c.