mosquitto mqtt 代理不会向订阅者发送超过 20 个发布数据包

Posted 2023-04-14

【中文标题】mosquitto mqtt 代理不会向订阅者发送超过 20 个发布数据包

【英文标题】：mosquitto mqtt broker won't send more than 20 publish packets to subscriber

【发布时间】：2021-04-03 14:55:39

【问题描述】：

我目前正在使用 python 开发一个 MQTT 客户端，并且可以创建发布和订阅 Mosquitto 代理的客户端。

问题在于，无论如何，mosquitto 代理最多只会向订阅者客户端发送 20 个 PUBLISH 数据包，即使它长时间保持连接也是如此。

如何配置 mosquitto 向订阅者客户端发送超过 20 个 PUBLISH 数据包？

蚊帐：

1608918436: Received PUBLISH from publisher (d1, q1, r0, m1, '/OS', ... (3 bytes))
1608918436: Sending PUBLISH to subscriber (d0, q1, r0, m17, '/OS', ... (3 bytes))
1608918436: Sending PUBACK to publisher (m1, rc0)
1608918438: Received PUBLISH from publisher (d1, q1, r0, m1, '/OS', ... (3 bytes))
1608918438: Sending PUBLISH to subscriber (d0, q1, r0, m18, '/OS', ... (3 bytes))
1608918438: Sending PUBACK to publisher (m1, rc0)
1608918440: Received PUBLISH from publisher (d1, q1, r0, m1, '/OS', ... (3 bytes))
1608918440: Sending PUBLISH to subscriber (d0, q1, r0, m19, '/OS', ... (3 bytes))
1608918440: Sending PUBACK to publisher (m1, rc0)
1608918442: Received PUBLISH from publisher (d1, q1, r0, m1, '/OS', ... (3 bytes))
1608918442: Sending PUBLISH to subscriber (d0, q1, r0, m20, '/OS', ... (3 bytes))

此时，mosquitto 代理不会向订阅者发送更多数据包，但订阅者客户端发送 PINGREQ 以保持与代理的连接时的 PINGRESP 除外。

1608918442: Sending PUBACK to publisher (m1, rc0)
1608918442: Received PINGREQ from subscriber
1608918442: Sending PINGRESP to subscriber
1608918444: Received PUBLISH from publisher (d1, q1, r0, m1, '/OS', ... (3 bytes))
1608918444: Sending PUBACK to publisher (m1, rc0)
1608918446: Received PUBLISH from publisher (d1, q1, r0, m1, '/OS', ... (3 bytes))
1608918446: Sending PUBACK to publisher (m1, rc0)

如果客户确实需要，我很乐意为客户提供代码。

稍后编辑：也许值得一提 如果一个主题有更多订阅者，则这种行为是不可观察的，代理会发送数据包而不会在任何时候停止。

【参考方案1】：

20 条消息听起来您正在达到最大的飞行消息数（未确认消息的最大数量）

消息是 QOS 1，因此您的客户需要确认它们。

【讨论】：

这意味着我没有正确阅读文档，所以请确保我已经理解，订阅者需要在收到 PUBLISH 后发送 PUBACK？

这确实是正确的。修改了我的订阅客户端，在收到 PUBLISH 后发送 PUBACK，“问题”消失了。

【参考方案2】：

通过将 mosquitto.conf 文件中的 ma​​x_inflight_messages 修改为 0 解决了这个问题。

【讨论】：

这不是正确的解决方案，您需要修复消息的确认

【参考方案3】：

对于完全相同的情况，我有不同的解决方案：

在我的发布者中，我没有围绕发布消息编写“client.loop_start()”和“client.loop_stop()”。添加这两行解决了这个问题。