Does the dup flag on the publish packet should be carried through sessions?

[Nicolas Vandeginste]

Hello everyone.

I'm implementing a mqtt client, and I can't find in the spec this specific case:

Client send Publish QOS 1 DUP 0.

wait

Client send Publish QOS 1 DUP 1.

Disconnect
Connect with session alive.
There, the client must redeliver the publish packet, but with a DUP of 0, or 1 ?

[Ken Dubuc]

From MQTT 5.0:

4.4 Message delivery retry
When a Client reconnects with Clean Start set to 0 and a session is present, both the Client and Server MUST resend any unacknowledged PUBLISH packets (where QoS > 0) and PUBREL packets using the original Packet Identifiers. This is the only circumstance where a Client or Server is REQUIRED to resend messages. Clients and Servers MUST NOT resend messages at any other time

Assuming these are all referring to the same message with the same packet identifiers, the first "Client send Publish QOS 1 DUP 1" violates the specification. The client is not allowed to resend unacknowledged PUBLISH packets without an intervening disconnection.

3.3.1.1 DUP

The DUP flag MUST be set to 1 by the Client or Server when it attempts to re-deliver a PUBLISH packet

 After the reconnection, the client must resend the PUBLISH packet with DUP set to 1.

[Nicolas Vandeginste]

Thanks!

One last thing:

The client store the message, fails before he could send anything.

When the client reconnect, it will send with a dup flag set to 1, even if it never sent the packet.

Correct ?

[Ken Dubuc]

3.3.1.1 DUP
If the DUP flag is set to 0, it indicates that this is the first occasion that the Client or Server has attempted to send this PUBLISH packet. If the DUP flag is set to 1, it indicates that this might be re-delivery of an earlier attempt to send the packet.

4.3.2 QoS 1: At least once delivery

In the QoS 1 delivery protocol, the sender

• MUST send a PUBLISH packet containing this Packet Identifier with QoS 1 and DUP flag set to 0

There's no way for an external observer to know whether a client has tried and failed to send a PUBLISH packet. Maybe the client did try to send a PUBLISH packet, and the TCP connection failed just before the packet hit the wire. So, there's no way for an external observer to absolutely prove, "the client should have set DUP to 0 for this PUBLISH". But, §4.3.2 says that if the sender "knows" that its the first time it's sending PUBLISH packet with a particular packet identifier — that is, the sender is certain that the receiver could not have previously received this PUBLISH packet — its DUP must be set to 0.

[Andy Stanford-Clark]

exactly, yes.

The DUP flag is really just “advisory”, as it only tells the receiver that there’s a possibility it has already seen that message, not, definitely that it *has*.

And as you rightly point out, DUP=0 tells the receiver it definitely hasn’t received this message before.

Andy

--
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+uns...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/mqtt/69d4f4b7-87e5-41ae-9797-d741af62d073o%40googlegroups.com.