| QoS2 Publishes reordered [message #1831190] |
Thu, 13 August 2020 09:18  |
 Andrew Walsh
Messages: 5
Registered: November 2019 |
Junior Member |
|
|
Hello,
I've been developing an embedded device which has an MQTT connection; I am using Mosquitto to test this, along with mosquitto_pub.
I have written a Bash script to split up a file into 256 byte chunks and publish them on a topic subscribed to by my embedded device. When my device receives the entire file, I find that it is different from the original source file; I'm able to find the first place that it differs and use this to determine which block seems to be incorrect. I then look for this block in a Wireshark capture, and I find a block with a message ID here, which appears to be out-of-order (I assume that Mosquitto will just increment a count when generating a message ID for a publish? I restarted Mosquitto prior to running this test, so that the message IDs would start at 1).
Specifically, I have publishes with message IDs from 1 to 220 (not checked them all, but I think they are all in order), and then I get a publish with a message ID of 542, which is then followed by a publish with a message ID of 221 (and subsequent publishes which, again, *appear* to be in order, without checking them thoroughly).
My embedded device is subscribing to the topic with QoS2, and my script tells mosquitto_pub to publish with QoS2, so I would expect that Mosquitto would forward the blocks in the same order that it has received them.
My device is also connecting with clean session = 0, but I've not configured the broker to keep the session in non-volatile storage.
I did wonder if the Bash script was publishing the blocks out-of-order, but if that was the case, I would not expect to see out-of-order message IDs, just out-of-order data.
I'm using Mosquitto 1.6.11, under Ubuntu 18.04 and I'm using TLS-PSK for security (although I don't expect that to cause this!). The broker IP address is 192.168.1.1, I'm running mosquitto_pub on the same machine and the embedded device (having IP 192.168.1.2) is connected to the Ethernet port on the same machine.
Am I missing something in my configuration, perhaps? If it's any use, I can provide a log file and a Wireshark capture.
Thanks.
[Updated on: Thu, 13 August 2020 09:26] Report message to a moderator |
|
|
|
|
| Re: QoS2 Publishes reordered [message #1831712 is a reply to message #1831190] |
Thu, 27 August 2020 08:31  |
Andrew Walsh
Messages: 5
Registered: November 2019 |
Junior Member |
|
|
Hi Roger,
Just a quick heads up (presumably you've not had time to consider this yet).
I've greatly improved the reliability of the MQTT connection made by my embedded device firmware (no doubt, if you examined the Wireshark capture, you'll see that there are many reconnections, etc - caused by a problem in the processor manufacturer-supplied SDK, as it turns out) and I've not seen the problem with re-ordering since (admittedly I've not made many tests).
It still seems to me, however, that the message reordering shouldn't happen, even with a dodgy connection, but maybe this will aid in recreation, when you do have time to look at it.
Best regards,
Andrew.
|
|
|
Powered by
FUDForum. Page generated in 0.02770 seconds
] 
Search
Help
Register
Login
Home
