Reputation: 1239
I'm looking into MQTT v3.1.1 and have the this question:
Can I safely assume that in a connection(no reconnect), the sender/receiver wouldn't see the next control packet for the same message identifier before sending/seeing the acknowledgement?
More precisely, I'm concerned about the following two cases.
In both cases, I assume:
I think the re-sent copies of control packets probably don't fit in the description of 4.4 Message delivery retry as there's no reconnect. Please correct me if I'm wrong.
For QoS 1, I'm not sure about PUBLISH#B which comes in before sending PUBBACK.
Likewise, for QoS 2, I'm not sure about PUBLISH#2 which comes in before sending PUBREC and PUBLISH#3 which comes in before seeing PUBREL.
Or, I can safely assume this situation should not happen so as it did happen then I can ignore those re-sent packets?
Upvotes: 1
Views: 523
Reputation: 1239
After reading some implementations and reflecting on this question for a while, I think I might be able to answer it by myself.
The key here is that a connection/socket-pair is duplex, meaning that the writing stream and the reading stream are independent and there's no way that content in one stream blocks that in another unless the application logic enforces such order.
A paranoid sender may write consecutive PUBLISHs without waiting for PUBBACKs, but a receiver that respects the specification is rightly to only fetch one from the TCP buffer, acknowledge a PUBBACK, then fetch and acknowledge another one.
Therefore, in the case in Fig 1, PUBLISH#B in the eyes of the receiver is just another PUBLISH and is processed after sending PUBACK#A.
In the case in Fig 2, the receiver responded PUBLISH#1 with PUBREC#1, then it tries to read a PUBREL but will instead find PUBLISH#2 in the buffer, in that situation, the specification states:
Until it has received the corresponding PUBREL packet, the Receiver MUST acknowledge any subsequent PUBLISH packet with the same Packet Identifier by sending a PUBREC. It MUST NOT cause duplicate messages to be delivered to any onward recipients in this case.
Upvotes: 1
Reputation: 59751
MQTT QOS acknowledgements are NOT end to end. They are between the publisher and the broker and then again separately between the broker and the subscriber.
There is no End to End delivery notifications in MQTT as there is no way for a publisher to know if there are 0, 1 or n subscribers to a given topic.
Upvotes: 0