SDK "hides" packetsend and packetreceive

[alinadima]

Hi. It seems like the v2 SDK is not exposing packetsend and packetreceive. To ensure that data is always eventually published and acknoledged as successful in spite of potential long periods of disconnects, it would be ideal to be able to have more granular control over when a message publish is attempted (and at that point maybe store the message in a local DB), and when the PUBACK is received (at which point you know the message was ack-ed by the broker). Why is the SDK not exposing this?

Even with persistent sessions, it is not a guarantee of successful delivery, so persistent local storage is needed.

Also, could you please explain what the behaviour of the client side persisten session implementation is? Will messages be queued best effort? What is the buffer size?

[jmklix]

The v2 sdk was designed so to handle the packetsend and packetreceive for you with the available options provided by AWS IoT. You can expect the persistent session to behave as described in the docs:

Whether or not to start a clean session with each reconnect. If True, the server will forget all subscriptions with each reconnect. Set False to request that the server resume an existing session or start a new session that may be resumed after a connection loss. The session_present bool in the connection callback informs whether an existing session was successfully resumed. If an existing session is resumed, the server remembers previous subscriptions and sends mesages (with QoS1 or higher) that were published while the client was offline.

So qos1 messages will be queued, while qos0 messages will not. There is no limit on the buffer size. You might want qos2, but that is not something that is provided by AWS IoT. You can implement your own checks locally (and save to a local db) to make sure that your messages get published.

[github-actions[bot]]

Hello! Reopening this discussion to make it searchable.