I wonder if the message sent order is preserved. That is, when a publisher sends a sequence of messages, is each subscriber guaranteed to receive the same sequence as the publisher had sent it? For both clean and persistent sessions?
Asked
Active
Viewed 1.8k times
2 Answers
57
A summary of the message ordering capabilities in MQTT 3.1.1 can be found in the specification itself here.
In summary:
- no guarantees are made about the relative ordering of messages published with different QoS values. (for example, QoS 0 can over take QoS 2 for example as it involves a single packet rather than the 4 packets of the latter).
- QoS 0 messages will be delivered in order (albeit messages may get lost)
- QoS 2 messages will be delivered in order
- QoS 1 allows for message duplicates - it is possible a duplicate will arrive after the first instance of the next message that was published.
QoS 1 ordering can be guaranteed if the client/broker only allow a single message inflight at any time.
knolleary
- 9,777
- 2
- 28
- 35
-
1v5.0 spec: https://docs.oasis-open.org/mqtt/mqtt/v5.0/os/mqtt-v5.0-os.html#_Toc3901240 – Slate Apr 21 '20 at 15:11
-
2but, is the order of the "first arrival" guaranteed in QoS1? – Stasik Apr 29 '20 at 13:19
-
1is the order of messages guaranteed only for each topic? – user7335295 Jun 30 '20 at 14:13
-
@user7335295 no guarantees are made across topics – knolleary Jul 01 '20 at 15:53
-
I couldn't understand how can you infer the following `QoS 2 messages will be delivered in order` from the documentation. I think order is not guarantee for QOS 1 and 2 unless `in-fight` message is set to 1 for broker and any publisher. – abhiarora May 13 '21 at 06:36
4
when a publisher sends a sequence of messages, is each subscriber guaranteed to receive the same sequence as the publisher had sent it?
This question has already been answered and well accepted but I see an issue with the following statement in the accepted answer.
QoS 2 messages will be delivered in order
As per the documentation, it is mentioned the sequence of packets PUBLISH,PUBREC, PUBREL, PUBCOMP will be maintained per topic across QOS 2 level messages. However, a subscriber can still receive in different order than published by publisher (possible but rare). The same logic is also applicable for QOS 1.
Let's see how:
PUBLISH packet has been send by broker for message m1.
PUBLISH packet has been send by broker for message m2.
PUBREC packet has been send by subscriber for message m1.
PUBREC packet has been send by subscriber for message m2.
PUBREL packet has been send by broker for message m1. But it got dropped.
PUBREL packet has been send by broker for message m2.
PUBCOMP packet has been send by subscriber for message m2.
Timeout for PUBREL packet at the broker has occurred for message m1. Broker will retry for message m1.
Broker re-transmits PUBREL packet for message m1.
PUBCOMP packet has been send by subscriber for message m1.
By above sequence, there is an possibility of the message m2 being processed first at the receiver. However, m1 was published before m2.
See this answer for further details.
Picture taken from u-blox.
abhiarora
- 9,743
- 5
- 32
- 57
-
I think it's worth noting that the 3.1 spec states that reconnection is the "only circumstance where a Client or Server is REQUIRED to redeliver messages" and the v5 spec [tightens this with](https://docs.oasis-open.org/mqtt/mqtt/v5.0/mqtt-v5.0.html#_Toc385349369) "Clients and Servers MUST NOT resend messages at any other time". As MQTT runs over connections "that provide ordered, lossless, bi-directional connections" a dropped message should lead to a disconnection. – Brits Aug 18 '22 at 04:18