QoS=2 for broker supporting only QoS=1 and no presistent session

Tech Talk
1

Per definition I have to use broker supporting only QoS=1 and not supporting persistent connection.

But I must ensure that messages arrive into their designated endpoints in order they were sent, and arrive only once - therefore I need QoS=2.

After consideration of possibilities one of the ways is to build something very similar to QoS=2 algorithm over QoS=0. However I have several questions on implementation of the QoS=2 in Mosquitto.

There’re generally no problems when all the devices in MQTT QoS=2 running and keeping their tables of unused IDs (see here. The problem and “metastalibity” happens when one of the devices forgets its table, or is interrupted in another way (e.g. rebooted) within the delivery and confirmation process.

  1. What happens to the process in case the device reboots? For example, broker sends PUBREC, device receives PUBREC, but device does not remember it has the process with this ID. Device may discard PUBREC as invalid, or respond with error. In both cases - what broker is doing with the process and data hanging in its queue as it does not receive PUBREL? I see potential zombie within the broker (message data is definitely being lost in this case).

  2. Device assigned message Id to be 100, sent the message to broker. Broker asks PUBREC with Id=100. But meanwhile device lost its table, prepared new message, accidentally assigned new message with same Id=100, and sent it to broker. If device receives PUBREC for Id=100, it will think last message is being processed. However at the same time broker will receive totally different message with Id=100. What broker does it it gets new message with no DUP flag set with the same Id? What client does if it receives PUBREC with Id=100 asking confirmation of another message sent earlier?

Are these cases being described anywhere in the documentation?

2

Hi,

For case 1, if the device receives a PUBREC it must respond with a PUBREL regardless of whether it remembers that ID. If it does not, it is non-compliant.

For case 2, if the broker receives a new PUBLISH for an existing message ID, and the topic, qos, or payload of the new publish do not match the original publish, then the old message will be purged from the broker and the new message used instead.

Regards,

Roger