Aws-iot-device-sdk-python-v2: 在 v2 中配置离线发布

目前的行为是：

• 所有发布的消息在发送之前都会排队，无论客户端是离线还是在线。
• 当客户端在线时（或者如果它已经在线），队列中的消息将按顺序发送。
• 但是：如果客户端在线，然后离线，则此时它会取消其队列中的每个 PUBLISH 和 SUBSCRIBE。

我们理解这是不一致的。 用户可能想要：
1) 消息总是排队直到可以发送
2) 如果客户端离线，或者在发送之前离线，消息会失败。

我们正在非常积极地评估改变这一点。 我会保持这个问题的开放性，我们会在做出更改（或正式确定当前行为）后进行更新

如果您现在想完全控制自己的命运，您可以构建自己的队列，一次向客户端发送 1 条消息。 如果成功，则发送下一个。 如果失败，则重试。 这也使您有机会完全控制消息排队的时间长度、将排队的消息数量等。

如果您现在想完全控制自己的命运，您可以构建自己的队列，一次向客户端发送 1 条消息。 如果成功，则发送下一个。 如果失败，则重试。 这也使您有机会完全控制消息排队的时间长度、将排队的消息数量等。

嗨@graebm。 你会怎么做？ 如果我的设备发布消息，但它处于离线状态，我会认为这些消息会保留在某种队列中吗？ 如果某些消息尚未发布，是否可以访问该队列并从中清除某些消息？

谢谢

@samvandamme您可以将服务质量 (qos) 设置为最多一次 (0)。
qos=mqtt.QoS.AT_MOST_ONCE
在同一台设备上订阅您要发布到的主题。 然后，为了确保发送消息，您维护已发布的消息列表。 仅当您收到有关该主题的消息时才删除它们。

目前的行为是：

• 所有发布的消息在发送之前都会排队，无论客户端是离线还是在线。
• 当客户端在线时（或者如果它已经在线），队列中的消息将按顺序发送。
• 但是：如果客户端在线，然后离线，则此时它会取消其队列中的每个 PUBLISH 和 SUBSCRIBE。

我们理解这是不一致的。 用户可能想要：

1. 消息总是排队，直到它们可以被发送
2. 如果客户端离线或在发送之前离线，消息将失败。

我们正在非常积极地评估改变这一点。 我会保持这个问题的开放性，我们会在做出更改（或正式确定当前行为）后进行更新

如果您现在想完全控制自己的命运，您可以构建自己的队列，一次向客户端发送 1 条消息。 如果成功，则发送下一个。 如果失败，则重试。 这也使您有机会完全控制消息排队的时间长度、将排队的消息数量等。

那么，处理设备离线一段时间的推荐方法是什么？

假设我有一个设备每 5 秒发送一次消息，该设备在线，消息到达 AWS IoT Core。 然后，设备失去连接 10 分钟，然后重新上线。 在 10 分钟离线期间尝试发布的所有消息会发生什么情况？ 它们会在设备再次上线后立即发布还是永远丢失？

前几条消息将丢失，而 sdk 还没有意识到它不再断开连接。 所有后续消息都将保存在队列中，并在连接恢复时发送。

在测试时，我在使用 pubsub 时丢失了前 5 条消息，它每秒发送消息。 所以大多数时候你只会丢失一条消息。

我也想更详细地了解这一点。 如上所述，离线时发布的消息进入队列，然后在连接重新上线时发布。

离线队列中存储了多少条消息？ 之前的 SDK 允许您选择、无限、无或指定数量。 我找不到任何关于此的文档。 这听起来像是无限的，但我想知道。 之前的 SDK 还允许您从队列的顶部或底部删除。 现在有可能吗？

之前的 SDK 还允许您为存储在队列中的消息选择消耗率。 现在可以配置了吗？ 如果不是，价值是多少？