QoS=1: PUBLISH and PUBACK loop ?

[cogitoergosum]

Hi,
Let there be subscribers S0, S1 ... Sn who have subscribed to a given topic with QoS=1. Amongst these subscribers, there is one subscriber Si which is located at a place with noticeable network latency issues.

Suppose, at time t0, a publisher has published to the topic with QoS=1 to which the aforementioned subscribers have subscribed to. Let, δt be the time the publisher is willing to wait for PUBACK. Let, at time ti, the broker has delivered the publication to Si and received the PUBACK too. Because of the network latency issues, it is possible that (ti-t0)>δt. This will trigger another PUBLISH from the publisher. In the meanwhile, the broker could have delivered to all the other remaining subscribers and eventually delivered the PUBACK to the publisher corresponding to the original publisher.

What should the publisher do now ? I see the following two options.

1. Delete the message of the first PUBLISH and wait for the PUBACK of the second PUBLISH message sent.
In the second PUBLISH, the (ti-t0)>δt is likely to happen again. And, thus, a third PUBLISH is sent. This can go on; causing all the subscribers to receive duplicate publications because of one subscriber whose latency issues triggered a PUBLISH again from the publisher. Then again, a QoS=1 could cause duplicate messages as per the spec.

2. Conclude delivery is over; ignore the (ti-t0)>δt of the second PUBLISH message sent.
Because the received PUBACK can be tallied with the message ID of the original PUBLISH message, the delivery can be considered over and the delay in the second time is ignored.

[Nicholas O'Leary]

Hi,

Your question assumes that the broker waits until all of the
subscriber flows have completed before completing the original publish
flow.

This is not how MQTT works.

The original publish flow should be completed independently of any
subsequent flows to subscribers of the topic.

Similarly, an MQTT client is never required to "timeout" a packet and
resend it. The only time a packet is resent is when a connection is
re-established and any previously in-flight flows are resent.

Regards,
Nick

> --
> To learn more about MQTT please visit http://mqtt.org
>
> To post to this group, send email to mq...@googlegroups.com
> To unsubscribe from this group, send email to
> mqtt+uns...@googlegroups.com
>
> For more options, visit this group at
> http://groups.google.com/group/mqtt

[Roger Light]

Hi Nick,

> Similarly, an MQTT client is never required to "timeout" a packet and
> resend it. The only time a packet is resent is when a connection is
> re-established and any previously in-flight flows are resent.

I'm not sure I agree with this statement. The spec says "If there is
an identified failure of either the communications link or the sending
device, or the acknowledgement message is not received after a
specified period of time, the sender resends the message with the DUP
bit set in the message header." By my reading, that contradicts what
you say. In theory TCP should guarantee the packet is received unless
there is a connection failure, but that may not happen in practice.

Cheers,

Roger

[Nicholas O'Leary]

Hi,

This is one of those areas we cleaned up the language around and I misremembered where it ended up.

Section 4.2 of the spec covers message retry. As you rightly point out, it does describe cases where message retry might occur. But It does conclude by saying clients are not required to perform message retry, but that brokers should.

Of course 'should' is not the same as 'must'.


Cheers,
Nick

[Nicholas O'Leary]

> Of course 'should' is not the same as 'must'.

Or, more accurately for the point you made that I was agreeing with, "not required to retry delivery" is not the same as "must not retry delivery" as I had suggested in my original reply.

N

[cogitoergosum]

>>Your question assumes that the broker waits until all of the subscriber flows have completed before completing the original publish flow.
>>This is not how MQTT works.
>>The original publish flow should be completed independently of any subsequent flows to subscribers of the topic.

Yes, that is what I assumed. In the spec for QoS=1 (http://ibm.co/KXtZDn), the PUBACK is clearly shown after the broker has delivered the publications to subscriber.

ನಾಗೇಶ್

[Roger Light]

Hi Nick,

> Section 4.2 of the spec covers message retry. As you rightly point out, it
> does describe cases where message retry might occur. But It does conclude by
> saying clients are not required to perform message retry, but that brokers
> should.

You're right, I should have carried on reading past where I found
something to support my claim.

Cheers,

Roger

[cogitoergosum]

Suppose, the publishing client does retry the PUBLISH because it didn't get a PUBACK within its wait period. Even then, we may run into the 'loop' type of situation ? That is, even though the publishing client received the PUBACK, a) it received it late and b) another PUBLISH was sent out already.

ನಾಗೇಶ್

[Roger Light]

On Tue, Jul 3, 2012 at 7:11 PM, cogitoergosum <nages...@gmail.com> wrote:
> Suppose, the publishing client does retry the PUBLISH because it didn't get
> a PUBACK within its wait period. Even then, we may run into the 'loop' type
> of situation ? That is, even though the publishing client received the
> PUBACK, a) it received it late and b) another PUBLISH was sent out already.

You're right, but I don't see a loop there. QoS 1 is defined as "at
least once" so the situation you describe with multiple messages is
perfectly acceptable. If you want there to be exactly one message
delivered then you should use QoS 2.

Cheers,

Roger

[cogitoergosum]

>>You're right, but I don't see a loop there.

Actually, it is not so much as a loop here. It is just that, the new PUBLISH is happening even when the earlier PUBLISH did deliver to all subscribers; albeit, a bit late.

Apart from the fact that, QoS=1 considers duplicate messages acceptable, there could be another scenario. Between the two PUBLISH (regardless of late PUBACK, etc.), yet another subscriber could have sent out a subscription for the same topic. This new subscriber should receive the publication regardless.

Roger, Nick, many thanks for your patience and answers !

ನಾಗೇಶ್