New MQTT 3.1.1 about DUP flag and PUBREL messagge (SUBSCRIBE and UNSUBSCRIBE too)

311 views
Skip to first unread message

Paolo Patierno

unread,
Nov 10, 2014, 8:28:22 AM11/10/14
to mq...@googlegroups.com
Hello,
I'm adding some changes to my M2Mqtt library for the new MQTT 3.1.1 version now as OASIS standard.

Just a point about PUBREL message and DUP flag ...

Speaking about DUP flag, the 3.1.0 version said that " ... this flag is set when the client or server attempts to re-deliver a PUBLISH, PUBREL, SUBSCRIBE or UNSUBSCRIBE message ..." so my library set dup = 1 when it tries to resend a PUBREL message.
In the 3.1.1 version, DUP flag is part of "flag bits" and it seems to be valid only for PUBLISH message so it is fixed to 0 for PUBREL message. This message has a flag bits equals and fixed to 0010.
Does it mean that I have to remove re-send PUBREL message ?
Is it the same thing with SUBSCRIBE and UNSUBSCRIBE messages that have 0010 as flag bits (as PUBREL) ? 

Thanks,
Paolo

Ian Craggs

unread,
Nov 10, 2014, 6:17:55 PM11/10/14
to mq...@googlegroups.com
Hi Paolo,

yes, in MQTT 3.1.1 the DUP flag is only used on the PUBLISH, not the PUBREL.  Personally, changing one but not the other seems odd, but I wasn't involved in that discussion.  I'm assuming the same is true for SUBSCRIBE and UNSUBSCRIBE too - that is, they don't use the DUP flag - but I'll have to check on that.

Ian

Paolo Patierno

unread,
Nov 11, 2014, 3:48:07 AM11/11/14
to mq...@googlegroups.com
Hi Ian,
It's important to know it because in this case I have to remove (from my M2Mqtt library) the retry logic with DUP flag set for all PUBREL, SUBSCRIBE and UNSUBSCRIBE message.
Who can give us the right answer ?

Thanks !
Paolo.

Darren Clark

unread,
Nov 11, 2014, 4:03:15 AM11/11/14
to mq...@googlegroups.com

Paolo,

I noticed that change in implementing a broker as well. The answer is that it should be as specced, only a DUP flag on PUBLISH. It kind of makes sense, since there really isn't any change in handling for any of the other message types regardless of it being set. The issue that I see with the change is more the general rule of "disconnect on a protocol violation" which would imply that any other messages with flat set are malformed. To implement properly and support 3.1 clients means tracking the protocol version in a bunch more places. I just ended up ignoring it in the other messages.

-Darren

--
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 post to this group, send email to mq...@googlegroups.com.
Visit this group at http://groups.google.com/group/mqtt.
For more options, visit https://groups.google.com/d/optout.

Dave Locke

unread,
Nov 11, 2014, 5:37:14 AM11/11/14
to mq...@googlegroups.com
Section 4.4 from the 3.1.1 spec provides the rationale for only using DUP on publish i.e. while a tcp socket is established, TCP provides reliable delivery of packets. Hence a subscribe will get a corresponding suback if the socket remains up.   Re-delivery is only specified in the spec when a socket breaks and a new connection is established. The only packets that are required to be redelivered are  PUBLISH and PUBREL in order to meet the requested QOS


4.4 Message delivery retry

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.


Non normative comment
Historically retransmission of Control Packets was required to overcome data loss on some older TCP networks. This might remain a concern where MQTT 3.1.1 implementations are to be deployed in such environments.

All the best
Dave

-Darren


Unless stated otherwise above:
IBM United Kingdom Limited - Registered in England and Wales with number 741598.
Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU

Paolo Patierno

unread,
Nov 11, 2014, 5:44:54 AM11/11/14
to mq...@googlegroups.com
Setting DUP = 1 in the PUBREL packet after reconnection with Clean Session set to 0, means to break the "flag bits" specification that is fixed to 0010 for PUBREL packet (in this case we have 1010 for PUBREL). As specification said, if invalid flags are received, the receiver MUST close the network connection.

We have two information in contrast between them.

Redeliver PUBREL with DUP = 1 means break "flag bits" fixed to 0010.

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

--
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

Dave Locke

unread,
Nov 11, 2014, 6:07:23 AM11/11/14
to mq...@googlegroups.com
I don't believe it breaks the spec,  The spec could be clearer but my reading is redelivery is required for PUBLISH and PUBREL in order to meet the requested QOS but the DUP flag is only set to 1 if the PUBLISH is resent.  For  PUBREL the DUP flag is always set to 0 even if a resend.


All the best
Dave

-Darren

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 http://groups.google.com/group/mqtt.
For more options, visit https://groups.google.com/d/optout.

--
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 post to this group, send email to

mq...@googlegroups.com.
Visit this group at http://groups.google.com/group/mqtt.
For more options, visit https://groups.google.com/d/optout.


Unless stated otherwise above:
IBM United Kingdom Limited - Registered in England and Wales with number 741598.
Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU

--

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 post to this group, send email to

mq...@googlegroups.com.
Visit this group at http://groups.google.com/group/mqtt.
For more options, visit https://groups.google.com/d/optout.

Paolo Patierno

unread,
Nov 11, 2014, 6:23:53 AM11/11/14
to mq...@googlegroups.com
Yes I think that the spec isn't clear on this because in the "Message delivery retry" paragraph it doesn't specify to not use DUP = 1 for resending PUBREL packet.
It could be more clearer :-)


However, if your reading is right, I agree with you ... resend PUBREL without DUP flag set (always 0).

It makes sense that DUP flag is set only on PUBLISH message, because the PUBLISH message has the data inside it and at application level it is important to know that the packet is a duplicate (previously received or not) to have a "duplicate detection" feature.
Resending PUBREL is only necessary to guarantee QoS level 2.

Paolo.

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

--
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


Unless stated otherwise above:
IBM United Kingdom Limited - Registered in England and Wales with number 741598.
Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU

--
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

pdn...@gmail.com

unread,
Nov 17, 2014, 7:14:10 AM11/17/14
to mq...@googlegroups.com
Hi Paolo

The reason that Section 4.4 (the Message Delivery Retry paragraph) doesn't say to set DUP to 0 in PUBREL is that - technically speaking - there is no DUP flag in a PUBREL packet.  In the old 3.1 spec, the 4 flags bits were defined (as DUP / QoS /  Retain) for all the MQTT packets. In 3.1.1 the flags bits are still there of course (in bits [3-0] of byte 1) but, as Table 2-2 shows,  the old meanings only apply to PUBLISH. In PUBREL you have to set the bits to 0,0,1,0 regardless of whether it's the first or a subsequent transmission of the packet. The reason for this is that there's nothing in the 3.1 protocol that really made use of that DUP bit on PUBREL, so what we are trying to do in 3.1.1 is to free it up for some possible alternative use in future versions.

So to summarise

i) In QoS 2, if you have sent a PUBREL and lose the connection before receiving a PUBCOMP you must resend the PUBRELwhen the connection is re-established - that's stated in [MQTT-4.4.0-1]
ii) The sender of the PUBREL is required to set the flags bits to 0,0,1,0 respectively in each PUBREL, whether it be the first one or a retransmission. This is stated in [MQTT-3.6.1-1].
iii) The receiver of a PUBREL that has the flags bits set to anything other than 0,0,1,0 is required to drop the connection. That's also stated in [MQTT-3.6.1-1].

Peter Niblett
Reply all
Reply to author
Forward
0 new messages