PUBLISH, QoS1, re-deliver "madness"

71 views
Skip to first unread message

Sebastian Wannemaker

unread,
Oct 6, 2017, 10:00:47 AM10/6/17
to MQTT
Hi,

after reading the standard a couple of times, I do not get the idea how to handle this situation:

 - Broker to client communication
 - Always on the same topic

PUBLISH QoS 1 DUP 0 /foo 12345 "Here is the payload 1"

     ... client gets the message but is busy ...
     ... brocker has a new message for topic /foo ...

PUBLISH QoS 0 DUP 0 /foo 67890 "Here is the payload 2"

     ... now the client passes "payload 1" to its recipients (aka onward delivery) ...

PUBACK 12345

     ... the client gets the second message and passes "payload 2" to it recipients ...
     ... BUT before the broker now receives this PUBACK, it re-delivers the message ...

PUBLISH QoS 1 DUP 1 /foo 12345 "Here is the payload 1"

     ... now the re-delivered messages arrives at the client ...

So, what happens now? I do not get it. Because the client already has sent "PUBACK 12345" it has
to treat the re-delivered message as a new one and thus delivers "payload 1" to it's recipients.
This is de facto an override of an actual value/payload with an old one.

I want to know who is responsible for this! :) Do I have a logical error in the PUBLISH/PUBACK stream?
Can such a situation happen and the client or their recipients must catch such a case with e.g. a
time stamp in the payload?

Any help and clarification on this matter are highly appreciated!

Thanks,
Sebastian

Paul Fremantle

unread,
Oct 6, 2017, 11:28:37 AM10/6/17
to mq...@googlegroups.com
Sebastian

The spec defines QOS1 as "at least once". In other words, it is completely within the spec for messages to be delivered twice or more under QOS1. 

 For QOS1 messages, there is a DUP flag and a packet id. This can help the client so it doesn't act twice on the same message. 

Paul 

PS I'm not sure I understand why you need the second payload in your scenario. The behaviour is the same either way. Maybe I misunderstood the problem?

--
To learn more about MQTT please visit http://mqtt.org
---
You received this message because you are subscribed to the Google Groups "MQTT" group.
To unsubscribe from this group and stop receiving emails from it, send an email to mqtt+unsubscribe@googlegroups.com.
To post to this group, send email to mq...@googlegroups.com.
Visit this group at https://groups.google.com/group/mqtt.
For more options, visit https://groups.google.com/d/optout.



--
Paul Fremantle
Doctoral Researcher, University of Portsmouth, School of Computing
Visiting Scientist, Institute of the Architecture of Application Systems, Stuttgart
Visiting Lecturer, Software Engineering Programme, Oxford University
Co-Founder, WSO2
Apache Member and Committer
twitter: pzfreo / skype: paulfremantle / blog: http://pzf.fremantle.org

Sebastian Wannemaker

unread,
Oct 6, 2017, 1:30:04 PM10/6/17
to MQTT
Hello Paul,

thanks for your reply.


The spec defines QOS1 as "at least once". In other words, it is completely within the spec for messages to be delivered twice or more under QOS1. 

Argh, okay, I missed the obvious. So receiving the payload twice is fine. I am still confused, though. To get things sorted out, are these statements okay:

 - client != "onward delivery" aka user of the client
 - If broker publishes message1 - message2, the client receives them in the exact same order (due to TCP)
 - If the client get message 1 - message 2 the USER may get them in reversed order, e.g. if message 1 is send with QOS2 and method A of "Figure 4.3 – QoS 2 protocol flow diagram, non normative example" is used and message 2 arrives between PUBREC and PUBREL. (This is because the specification does not cover the issues of the user of a client at all. (?))
 - In case of a re-deliver of a QOS1 message it may be possible that the retry is interpreted as a second (new) message (like in my example: 1 - 2 - 1*)

 For QOS1 messages, there is a DUP flag and a packet id. This can help the client so it doesn't act twice on the same message. 

I thought that too but how? The standard says - regarding the receiver: "After it has sent a PUBACK Packet the Receiver MUST treat any incoming PUBLISH packet that contains the same Packet Identifier *as being a new publication*, irrespective of the setting of its DUP flag."
 

Paul 

PS I'm not sure I understand why you need the second payload in your scenario. The behaviour is the same either way. Maybe I misunderstood the problem?

If I would understand my problem ;) The problem was that I did not differentiate between the client/receiver and the user of the client and that the standard does not specify in which order the client propagates messages to its users.


Sebastian
 

To unsubscribe from this group and stop receiving emails from it, send an email to mqtt+uns...@googlegroups.com.

To post to this group, send email to mq...@googlegroups.com.
Visit this group at https://groups.google.com/group/mqtt.
For more options, visit https://groups.google.com/d/optout.

Nick O'Leary

unread,
Oct 6, 2017, 1:40:03 PM10/6/17
to mq...@googlegroups.com

 - If broker publishes message1 - message2, the client receives them in the exact same order (due to TCP)

If the broker writes message1 PUB to the network, followed by message2 PUB, then yes, they will arrive at the client in that order.

 - If the client get message 1 - message 2 the USER may get them in reversed order:

The ordering of messages is only preserved within a given QoS. So two messages of the same qos will always arrive at the user in the order they were published.
Given two messages of differing qos, it is possible for the lower qos message to arrive ahead of a higher qos message.

 - In case of a re-deliver of a QOS1 message it may be possible that the retry is interpreted as a second (new) message (like in my example: 1 - 2 - 1*)
If the client had received the original message, processed it and written its PUBACK to the network, that client is no longer required to 'remember' about that message. So if a redelivery occurs in that circumstance, the client will consider it a 'new' message. To be honest, the DUP flag in the packet isn't very useful - if you care about deduplication, either use QoS 2 or build it into the consuming application.

On the subject of redelivery - the broker is only required to resend a qos 1 message in the event of a connection breaking and reconnecting. There is no requirement for a sender of a qos1 to retry whilst the connection is still alive (although they may) - http://docs.oasis-open.org/mqtt/mqtt/v3.1.1/os/mqtt-v3.1.1-os.html#_Toc398718103

Nick 


To unsubscribe from this group and stop receiving emails from it, send an email to mqtt+unsubscribe@googlegroups.com.

Sebastian Wannemaker

unread,
Oct 13, 2017, 10:05:39 AM10/13/17
to MQTT
Thanks, this topic is now much clearer for me.
Reply all
Reply to author
Forward
0 new messages