MQTT3: Behavior when receiving unexpected packet ID.

110 views
Skip to first unread message

Nicolas Vandeginste

unread,
Apr 20, 2021, 7:59:18 PM4/20/21
to MQTT
Hello,
I'm currently implementing an MQTT3 client. 

Which behavior should a client/server have when it receives a PUBACK/PUBREC/PUBREL/PUBCOMP from an unknown ID?
The spec doesn't specify this case, is it a protocol violation and the connexion should be closed?

Thanks

Dustin Sallings

unread,
Apr 20, 2021, 11:37:10 PM4/20/21
to mq...@googlegroups.com
If you see something like this, something went very wrong and you shouldn't assume you've got a good state.  Disconnecting makes sense. 

Nick O'Leary

unread,
Apr 21, 2021, 4:42:12 AM4/21/21
to mq...@googlegroups.com
> Disconnecting makes sense. 

Not in all cases - it depends on how the client chooses to manage its state around the different QoS values.

For example, in the case of QoS2:
 - client receives PUBREL
 - client sends PUBCOMP and removes any stored state related to that ID
 - the network breaks so the PUBCOMP never reaches the broker
 - at some point the client reconnects, the broker resends the PUBREL
 - the client has now received a PUBREL for an ID it doesn't know about.
In that case, the correct processing is for the client to assume the PUBREL is being received for a message it has already dealt with, so should respond normally with a PUBCOMP.



--
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/CAFnwT5-hY%3DyTn4KW_3z9N3exUpU%3DaSUbiX%2BL7OE6qaXB6PQ-Jw%40mail.gmail.com.

Andy Stanford-Clark

unread,
Apr 21, 2021, 6:52:23 PM4/21/21
to mq...@googlegroups.com
yes - I’m surprised we didn’t mention it in the spec - 
if you receive an apparently unsolicited (i.e for which you have no associated message state) …

qos1 PUBACK you just ignore it.

qos2 PUBREC you send the PUBREL with the same ID  - this probably shouldn’t happen, as you need to keep state until you get the PUBCOMP, as you might have to retry the PUBREL. But you might have lost your state through a power fail for example. 

qos2 PUBREL you send the PUBCOMP with the same ID (for the reason Nick explained).

qos2 PUBCOMP ignore it. 

This is why you shouldn’t re-use your message IDs too quickly, but keep incrementing (and wrapping) for each new message

Andy




Nicolas Vandeginste

unread,
Apr 21, 2021, 7:03:55 PM4/21/21
to mq...@googlegroups.com
I have a mechanism that allows me to detect when these packet ids are really available.
Should I drop the connection if I know for sure that this packet ID doesn't exist at all?

To view this discussion on the web visit https://groups.google.com/d/msgid/mqtt/F0D90290-3F0F-4318-AFDA-35F63ACF5566%40stanford-clark.com.

Andy Stanford-Clark

unread,
Apr 22, 2021, 4:31:15 AM4/22/21
to 'Simon Walters' via MQTT
Well - the problem is “clean up”…. if you drop the connection, the other end won’t know why. 
So it will just reconnect and retry - forever.

I think (without too much deep thought or analysis) that it’s best to drive the flow through to completion - then the other end can do what it needs to do and will get it off the books and hopefully leave you alone. 
It should be logged, and an admin watching the logs should investigate

It’s a good philosophical debate :)

Andy




Zaiming Shi

unread,
Apr 22, 2021, 4:51:57 AM4/22/21
to mq...@googlegroups.com
very good point there Andy.
If such situations happen mostly when re-connect,
disconnecting again seems to only make things worse.

Andy Stanford-Clark

unread,
Apr 22, 2021, 5:11:59 AM4/22/21
to 'Simon Walters' via MQTT
Yes, we did observe once that because we’re using TCP/IP for MQTT connections, you should actually only need to retry any message upon reconnection.
Doing it after 10 seconds (say) shouldn’t be needed, as TCP/IP *will* deliver it, unless the connection has broken (hence retrying on reconnect)…
And on a slow, backed-up, full queues, lots of retries (at the TCP level) link, sending MQTT retransmissions of (especially long) messages on a still viable link, just makes matters worse.

Andy


Dustin Sallings

unread,
Apr 22, 2021, 10:39:30 AM4/22/21
to mq...@googlegroups.com
I've had bugs with brokers where the state got bad enough that I just had to create a new session.  Not that creating a new session programmatically on failure is recommended, but sometimes there are bugs.

I do recall running into these issues writing clients now... I'm not sure what I disconnect for anymore from the client side.  I guess I should look before answering. :)

To view this discussion on the web visit https://groups.google.com/d/msgid/mqtt/CAPNZrFWE-MhGxU1Zj6E5JQZkq9%2BJsLJtjrz6xXw9sRT%3D8XTo4g%40mail.gmail.com.
Reply all
Reply to author
Forward
0 new messages