消息顺序是否保留在MQTT消息中?

Kar*_*Kar 23 mqtt

我想知道是否保留了消息发送顺序.也就是说,当发布者发送一系列消息时,每个订阅者是否保证收到与发布者发送的相同的序列?对于干净和持久的会话?

kno*_*ary 38

MQTT 3.1.1中的消息排序功能摘要可以在此处的规范中找到.

综上所述:

  • 不保证使用不同QoS值发布的消息的相对排序.(例如,QoS 0可以过度采用QoS 2,因为它涉及单个数据包而不是后者的4个数据包).
  • QoS 0消息将按顺序传递(尽管消息可能会丢失)
  • QoS 2消息将按顺序传递
  • QoS 1允许消息重复 - 在发布的下一条消息的第一个实例之后,可能会出现重复.

如果客户端/代理在任何时候只允许单个消息飞行,则可以保证QoS 1排序.

  • 但是,QoS1中是否保证了“先到”的顺序呢? (2认同)

abh*_*ora 5

当发布者发送消息序列时,是否保证每个订阅者收到与发布者发送的序列相同的序列?

这个问题已经得到回答并被广泛接受,但我在接受的答案中发现以下声明存在问题。

QoS 2 消息将按顺序传递

根据文档,提到数据包的顺序PUBLISH将按PUBREC主题PUBREL跨级别消息PUBCOMP进行维护。QOS 2但是,订阅者仍然可以按照与发布者发布的顺序不同的顺序接收(可能但很少见)。同样的逻辑也适用于QOS 1

让我们看看如何:

  1. 消息 m1 的代理已发送 PUBLISH 数据包。

  2. 消息 m2 的代理已发送 PUBLISH 数据包。

  3. PUBREC 数据包已由消息 m1 的订阅者发送。

  4. PUBREC 数据包已由消息 m2 的订阅者发送。

  5. PUBREL 数据包已由消息 m1 的代理发送。但它被丢弃了。

  6. PUBREL 数据包已由消息 m2 的代理发送。

  7. PUBCOMP 数据包已由消息 m2 的订阅者发送。

  8. 消息 m1 的代理处 PUBREL 数据包发生超时。Broker 将重试消息 m1。

  9. 代理重新传输消息 m1 的 PUBREL 数据包。

  10. PUBCOMP 数据包已由消息 m1 的订阅者发送。

通过上述顺序,消息m2有可能首先在接收方被处理。然而,m1 在 m2 之前发布。

有关更多详细信息,请参阅此答案。

在此输入图像描述

图片取自u-blox