Paho MQTT 客户端缓存消息在 Mosquitto 服务器上的意外行为答案

【问题标题】：Unexpected behaviour of cached messages of Paho MQTT client on Mosquitto serverPaho MQTT 客户端缓存消息在 Mosquitto 服务器上的意外行为
【发布时间】：2020-05-05 06:33:59
【问题描述】：

我确实在我的应用程序中使用了 PAHO C 客户端库。我确实订阅了 MQTTAsync_subscribe() 和 QoS 设置为 1 的主题。据我了解，1 意味着至少一次向客户端发送消息。

我断开了订阅主题的客户端，而发布主题的客户端仍在向 Mosquitto 代理发送消息。如果我在几个小时后启动订阅者，我会在订阅者关闭时从最后一条消息开始获得所有缓冲的消息。到现在为止还挺好！但问题是，消息到达的时间间隔与发布者发送新消息的时间间隔相同。这样一来，您将永远不会得到发布者排队的最新消息。

我希望 Mosquitto 代理尝试将所有待处理的消息一个接一个地发送给客户端，而不是在发布新消息时发送一条旧消息。

也许有人可以帮助我理解为什么会发生这种情况或如何克服这种情况？

【问题讨论】：

您使用的是什么版本的 mosquitto。另外，您是如何处理客户端中的消息的，您是否在消息传递回调中执行任何长时间运行的任务？

标签： mqtt mosquitto paho

【解决方案1】：

当客户端重新连接时，队列中的消息应该全部被批量传递。

它们没有排队并以相同的时间偏移量交付，mosquitto 甚至不会保留到达时间来进行时间偏移延迟交付（MQTT v5 消息保留到达时间，因为它们现在可以具有 TTL值，但这仅用于从队列中删除过期消息，而不是延迟延迟传递）。

【讨论】：

嗯，好的。但是，只要排队的消息以比新消息更短的时间间隔发送，您的解释就可以了。只要使用新消息作为触发器来发送旧消息（不超过最后一条），您就永远不会清空队列并到达最新消息...
它们应该在您重新连接/订阅相关主题时立即发送，它们不会由客户端重新连接以外的任何东西触发。如果您排队/发布新消息的速度超过了客户端的处理速度，那么问题在于客户端，而不是代理。
是的，过载可能会导致您所描述的情况。但是为了测试目的，我以 5 秒的间隔发送消息。这不应该引起这样的问题。旧消息也以 5 秒的间隔到达...
不是这样的，消息是立即送达的，你是否在每条消息中都有一个唯一标识符来证明它们被延迟而不是你只是看到新消息？
是的，我确实将当前时间戳作为字符串发送，并且我确实看到了几个小时前的时间戳，在订阅者关闭之前。而且我还取消订阅有关关闭订阅者的主题。