The client has a built-in persistence mechanism to ensure reliable messaging for the quality of service (QoS) in use. That approach means that messages published by the client at QoS 1 and QoS 2 are persisted until the client receives the acknowledgment from the server that the delivery completed successfully.
In the same way, any message received by the client at QoS 2 is saved to the persistent storage until the delivery flow is completed and then the message is passed to the application. Persistence enables the client to resume (and complete) any in-flight message flow in case the connection with the server drops.
Persistence is defined when a client is created using the API function MQTTClient_create
. An application can then call getPendingDeliveryTokens
to retrieve information about any outstanding message deliveries before connecting the client to the server. A client can be created using one of the following types of persistence:
- Default: The default persistence is based on the local file system. Disk write-caching is disabled in the system.
- None: The messages reside only in memory. In the event of a power failure, any in-flight messages are lost.
- User: An application can provide its own persistence mechanism by implementing the functions in the header file MQTTClientPersistence.h. Note that the persistence API uses a hashtable model where persistable data is stored and retrieved using a key.
Parent topic: Using the MQTT C Client: XPD622