Client side delivery guarantee (QoS 1 or 2)

[yuridiniz]

Steps:

1 - Connect to Broker 2 - Subscribe to the topic "test/" 2 - Disconnect the client 3 - Send a message to a topic "test/" with QoS 1 or 2 4 - Close the application 5 - Open the application 6 - Connect to Broker

Result:

Messages sent with QoS 1 and 2 will be lost

Expected results

Resend messages after restarting the application using MQTT only

By MQTT protocol specification, when using QoS 1 or 2, you are guaranteed that the message arrives in the broker, but if the client is offline and restart the application, the message will be loss

Using ManagedClient I will have the guarantee that the message will be delivered, but it has some limitations like CleanSession = false, so I can not guarantee that QoS 1 or 2 will reach me

It seems to me that the QoS 1 and 2 delivery guarantee defined in the MQTT protocol is not being met.

Is there any plan for this?

[jenscski]

If I understand you correct, you need to add a implementation of IManagedMqttClientStorage to ManagedMqttClientOptions.Storage.

You can look at a simple implementation from the tests, https://github.com/chkr1011/MQTTnet/blob/15d4ee4d68ef7191aab756707717eacf36ee31e0/Tests/MQTTnet.TestApp.NetCore/ManagedClientTest.cs#L75-L101

[yuridiniz]

Thanks, I had implemented this example to look at the operation of ManagedClient, the problem of ManagedClient is that it does not allow session usage, so messages sent by other clients with QoS 1 or 2 will not be received by offline clients

[chkr1011]

Support for sessions in ManagedClient is planned but not yet completed. I assume it will be implemented in 2.9.0.

[SeppPenner]

What's the status of this @chkr1011?

[MarekLani]

@chkr1011 please any update on offline session support for managed client?

[raffaeler]

The storage on the managed client can't work as a workaround for QoS for two reasons:

1. interoperating with other system
2. can't choose the reliability feature on a per-message basis. Currently you need one "reliable/storage-enabled" client and another one without storage.

While I can "hack" the storage class to overcome the second problem, it is not a clean solution. For this reason I am switching to a mix of MQTT and REST, which raise the complexity of the entire solution.

Hope to see this implemented soon. Thanks for the efforts

[ramonsmits]

@chkr1011 Does managed client support sessions? I searched in the release notes on session but I couldn't find any related items.

[chkr1011]

No the managed client does not yet support sessions.

[raffaeler]

@chkr1011 Could you please clarify what is the "close issue" related to? The thread was about client-side guarantee (QoS of the specs). Will the library provide this or not? Thanks!

[chkr1011]

Ah that was a mistake. This feature will be added as soon as there is time for it. As long as this is not implemented I recommend to use the regular client and doing the storage of the application messages manually.

[tmds]

As long as this is not implemented I recommend to use the regular client and doing the storage of the application messages manually.

This suggests the issue is on the client side.

6 - Connect to Broker

If this step happens with CleanSession = false and the same same ClientId, the broker should send back the messages that it stored for that session.

If it doesn't, that is an issue with the broker.