0

The MQTT 3.1.1 spec, section 3.1.2.4 says

If CleanSession is set to 1, the Client and Server MUST discard any previous Session and start a new one. This Session lasts as long as the Network Connection. State data associated with this Session MUST NOT be reused in any subsequent Session [MQTT-3.1.2-6].

The Session state in the Client consists of:

· QoS 1 and QoS 2 messages which have been sent to the Server, but have not been completely acknowledged.

· QoS 2 messages which have been received from the Server, but have not been completely acknowledged.

Meaning the client must discard unacked QoS 1 messages and not reuse any data from them in the new session.

However, there seem to be plenty of examples in the wild of clients resending unacked QoS 1 messages on a clean session reconnect.

Resending unacked messages is almost indistinguishable in this case from sending a new message with the same content, except for the DUP flag - is it wrong for a client to set the DUP flag when retrying unacked messages on a clean session?

Also, surely it's a violation to retry QoS 2 messages on a clean session reconnect, since that could potentially break the at most once delivery guarantee?

Andy
  • 7,885
  • 5
  • 55
  • 61
  • You are making assertions without presenting any evidence, can you provide details for the statement "However, there seem to be plenty of examples in the wild of clients resending unacked QoS 1 messages on a clean session reconnect." ? – hardillb Aug 12 '21 at 22:44
  • Actually I may be wrong, I had assumed because my boss was saying he had worked with clients that do this and thought this was why you would use QoS 1 with a clean session, and then I googled about the subject and skimmed some results too quickly. Confirmation bias... – Andy Aug 13 '21 at 17:33
  • However, given that the spec says "When a Client reconnects with CleanSession set to 0, both the Client and Server MUST re-send any unacknowledged PUBLISH Packets (where QoS > 0) and PUBREL Packets using their original Packet Identifiers [MQTT-4.4.0-1]. This is the only circumstance where a Client or Server is REQUIRED to redeliver messages." it implies that there may be other circumstances when redelivery is desirable. But I guess that's probably talking about retrying delivery after some timeout, rather than on clean reconnect – Andy Aug 13 '21 at 17:34
  • Also QoS 1/2 seems almost pointless with a clean session so I'm wondering why the spec even allows it and what the purpose of that is – Andy Aug 13 '21 at 17:43
  • Stack Overflow really isn't the pace for a discussion of the MQTT spec. – hardillb Aug 13 '21 at 17:46
  • Okay, do you know where would be a good place for me to ask questions like this? – Andy Aug 13 '21 at 17:47
  • Also I'm kind of confused why SO wouldn't be a good place for asking questions about understanding of specifications in general – Andy Aug 13 '21 at 17:48
  • "This is the only circumstance where a Client or Server is REQUIRED to redeliver messages" becomes "Clients and Servers MUST NOT resend messages at any other time" in the [V5 spec](https://docs.oasis-open.org/mqtt/mqtt/v5.0/mqtt-v5.0.html#_Toc385349369) - some V3 brokers do retry delivery of unacknowledged messages periodically but there are issues with this (see [Mosquitto changelog](https://github.com/eclipse/mosquitto/blob/master/ChangeLog.txt) entry for v1.5). As @hardillb says your question invites general discussion of the spec which is not a great fit for a question/answer site. – Brits Aug 13 '21 at 20:20

0 Answers0