[BUG] Out of order PUBACKs are ignored

[serfreeman1337]

Describe the bug Out of order PUBACKs are being ignored.

For QOS 2 publishes that were sent in loop I got packet ids in order 3, 4, 5, 6, 7, but from MQTT server I got out of order PUBACKs: 3, 6, 5, 7, 4

Resulting onPublish was only called for packet id 3 and 4.

Observed on ESP8266 using Non TLS version. Arduino IDE with latest esp8266 board library.

Expected behaviour onPublish should be called for every PUBACK regardles of order.

[serfreeman1337]

Simple commenting out this break made it work for me: https://github.com/bertmelis/espMqttClient/blob/835bcfb16853cd19637c2f7001df24320425cfb2/src/MqttClient.cpp#L486

I see that QOS 2 behavior is differs from async-mqtt-client. This library sends QOS 2 publish right away, while async-mqtt-client waits for PUBACK before sending anything else.

espMqttClient


async-mqtt-client


[bertmelis]

PUBACKS should be sent in the order in which the PUBs are sent. That is a MUST: http://docs.oasis-open.org/mqtt/mqtt/v3.1.1/os/mqtt-v3.1.1-os.html#_Toc398718105 That is why the callbacks are not called.

I didn't implement retry yet because I've never seen this behaviour. I'll put it on the top of the TODO list.

And indeed, this lib doesn't wait for PUB packets to be acknowledged before sending new ones. It's to speed up things.

Do you also have a wireshark when the PUB packets were sent by the client (or received by the broker)?

[bertmelis]

Hmmm, I might be mistaken here. The spec talks about MUSTs for clients. The broker has more freedom.

[serfreeman1337]

I'm using ThingsBoard as mqtt server. I've checked traffic on the server side and indeed it's mqtt server which sends out of order PUBACKs.

wireshark on mqtt server side


[bertmelis]

I created a branch/PR to remove the message ordering check. I reread the specification and concluded the ordering is not mandatory for the broker. So, the client has to accept the out of order ACKs. I assume you agree?

[bertmelis]

Now, it's more complicated than this. If in the middle of this unordered acking, the connection interrupts, the client still has to resend the original messages in the same order. the PR is therefore not final because this requirement is not met anymore.

[serfreeman1337]

I found that this issue only happens with ThingsBoard's "Gateway API" topics (v1/gateway/*). With default topics (v1/devices/me/*) all PUBACKs are in order, even if I publish more than 150 messages at once.

So, it's more thingsboard server issue. I'll implement queing for gateway topics myself then.

Thank you for pointing out that it might be a server problem.

[bertmelis]

In this case the client in too strict. I'll solve it in the next release. IT wiill take some time to implement "retransmission".

[bertmelis]

Closing this in favour of #46.