0

enter image description here

Assume the Receiver has recieved the PUBREL from the Sender, according to the standard, it would discard the packet id. If the PUBCOMP message does not arrive at the Sender successfully, the Sender would retry to send PUBREL message and when it arrives at the Receiver, the id has been discarded at the first time when PUBREL arrived. Will the sender respond a proper PUBCOMP? This means the receiver still stores the id after gets PUBREL and it is contradictory.

Most articles just tell that the Sender would retry to send but not tell why. Thanks for your kind answer.

Cold snap
  • 15
  • 4

1 Answers1

1

For MQTT3.1.1 see MQTT-4.3.3-2:

MUST respond to a PUBREL packet by sending a PUBCOMP packet containing the same Packet Identifier as the PUBREL.

MQTT v5 has similar rules but the PUBREL includes a "PUBREL Reason Code" which can be set to 0x92 to indicate:

The Packet Identifier is not known. This is not an error during recovery, but at other times indicates a mismatch between the Session State on the Client and Server.

In both cases the spec seems quite clear, if you receive a PUBREL you must respond with a PUBCOMP. So the why could be "because the spec says so", but in reality this approach just makes sense (not sending the packet would mean the PUBREL would be resent the next time the connection is reestablished).

This means the receiver still stores the id after gets PUBREL and it is contradictory.

As per the spec the ID comes from the PUBREL packet, not the session state (which has been deleted previously in your example), so there is no contradiction.

Brits
  • 14,829
  • 2
  • 18
  • 31
  • I wonder whether the receiver still needs to record the session state after it sends PUBCOMP. Only that，if the PUBCOMP does not come to the sender successfully and the receiver could respond a proper PUBCOMP after the sender resends a PUBREL. Suppose the session state is fully removed, the sender could not respond properly if PUBCOMP failed to reach the sender next time. – Cold snap Jun 16 '23 at 03:46
  • The [spec](http://docs.oasis-open.org/mqtt/mqtt/v3.1.1/os/mqtt-v3.1.1-os.html#_Toc385349231) is pretty clear on what the session state contains "QoS 2 messages which have been received from the Server, but have not been completely acknowledged". Once the `PUBCOMP` has been sent the message has been completely acknowledged. If the publisher does not receive the `PUBCOMP` then it will resend the `PUBREL` and the subscriber will respond using the packet id in the `PUBREL` (despite having no info on the request in its session state). – Brits Jun 16 '23 at 03:54
  • Thank you for your kind explanation. I did not notice the Clean Session part before. Now I got it – Cold snap Jun 16 '23 at 06:20