Is it need to add retry mechanism when publisher implement Qos1/2

[chenchuangchn]

Hi~ I have an question about the Qos2 implement of MQTTPublish() fuction. As we know Qos2 guarantee s Exactly once delivery. The progress is sender send PUBLISH-->receiver receive PUBLISH, store Packet Identifier or message and send PUBREC--> sender receive PUBREC and send PUBREL-->receiver receive PUBREL and send PUBCOMP-->send receive PUBCOMP. But there are some questions:

1. In MQTTPublish() fuctions., There is no operation to store in the nonvolatile memory.
2. That progress is only implement at once. If the network is slow, some message maybe lost, but there is no retry to support. Then the MQTTPublish() fuction couldn't achieve the Qos2 decreption(Exactly once delivery) since lost message . From what has been discussed above, Is it need to add retry mechanism mechanism in MQTTPublish()?

[icraggs]

1) See http://modelbasedtesting.co.uk/2013/11/24/mqtt-qos-and-persistence/ Without persistence, QoS 1 and 2 protect against connection loss. A persistence interface is in the main paho C client - is the embedded client the best choice for you? What OS/hardware are you using?

2) It looks like re-sending is not implemented in MQTTClient-C, as opposed to MQTTClient (the C++ version). I didn't implement the C version, and I hadn't realised that was not part of it. So, yes, that is an omission - it should be implemented the same way as the C++ client library - the intention is to keep the codebases the same except for the C/C++ differences.

Message retry is only attempted on reconnection - in connect, not publish (see C++ MQTTClient). This is the standard approach in MQTT versions 3.1.1 and onwards. In practice, I and others have found that retries during a connection only exacerbate the problem of an overloaded network.

I'

[chenchuangchn]

Thanks for tolerating my sick English

1. I'm using Linux on the arm board, so I think it's suitable to use embedded client.
2. I'm sorry I'm not familiar with c++(I will learn it later), so I couldn't read the publish function well. But according MQTT spec, I think that it should re-send PUBLISH or PUBREL, holding the same messageid, when the client doesn't receive PUBREC and PUBCOMP, isn't it? If it is, will you fix the "omission" in the near future? : ). In addition, I also have a question about Qos2 in MQTT spec. In my mind, when the client can't receive PUBCOMP, it will re-send PUBREL, Which can lead it to send the same message to receiver again(at least once not exactly once ). Is my understanding correct? Thank you again.