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

【问题标题】：mosquitto mqtt broker won't send more than 20 publish packets to subscribermosquitto mqtt 代理不会向订阅者发送超过 20 个发布数据包
【发布时间】：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)

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

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

【问题讨论】：

标签： python networking mqtt mosquitto

【解决方案1】：

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

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

【讨论】：

这意味着我没有正确阅读文档，所以请确保我已经理解，订阅者需要在收到 PUBLISH 后发送 PUBACK？
这确实是正确的。修改了我的订阅客户端，在收到 PUBLISH 后发送 PUBACK，“问题”消失了。

【解决方案2】：

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

【讨论】：

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

【解决方案3】：

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

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

【讨论】：