【问题标题】:When publishing message with mqtt QoS 2, can it be lost?使用 mqtt QoS 2 发布消息时,会不会丢失?
【发布时间】:2018-11-28 22:40:06
【问题描述】:

我正在尝试使用 MQTT-Client Framework 实现 MQTT 客户端。我想确保我尝试发布的每条消息都会到达代理。我无法弄清楚 QOS2 的确切含义:它声明一条消息将只发送一次。是不是意味着当连接丢失时,它会在重新连接后自动尝试重传消息?或者这应该由应用程序处理?

同样在这个库中,默认情况下会自动重新连接?还是需要检查connectionLost是否发生,然后尝试重新连接?

【问题讨论】:

    标签: mqtt ios-mqtt-client-framework


    【解决方案1】:

    MQTT QoS 级别是对向接收方传递消息的保证 - 而不是发送方发送/重新发送消息的频率。请参阅 QoS section in the MQTT specoverview of MQTT QoS

    使用 MQTT QoS2 发布的消息意味着它将只发送一次。可以多次发送消息,以实现这种只发送一次的保证。

    MQTT 的至少一次交付方面是使用 PUBLISH/PUBREC 握手实现的。如果发布者没有收到确认其已发布消息的 PUBREC 数据包,则发布者将继续重新发送设置了 DUP 标志的 PUBLISH 消息。

    使用额外的 PUBREL/PUBCOMP 握手来实现 QoS2 的恰好一次交付方面。接收者可以在two different points选择转发消息并丢弃重复消息。

    是不是表示当连接丢失时会尝试重传 重新连接后自动发送消息?或者这应该是 由应用处理?

    MQTT 规范涵盖message delivery retries

    当客户端在 CleanSession 设置为 0 的情况下重新连接时,客户端 并且服务器必须重新发送任何未确认的 PUBLISH 数据包(其中 QoS > 0) 和 PUBREL 数据包使用其原始数据包标识符。这是客户端或服务器的唯一情况 需要重新发送消息。

    因此,如果您的客户端遵循规范并且您使用的是持久会话 (CleanSession = 0),那么消息将被重新传输。

    【讨论】:

      猜你喜欢
      • 1970-01-01
      • 1970-01-01
      • 1970-01-01
      • 1970-01-01
      • 1970-01-01
      • 1970-01-01
      • 1970-01-01
      • 1970-01-01
      • 2015-12-05
      相关资源
      最近更新 更多