关于 MQTT on_log 输出的问题

Questions on MQTT on_log output

我刚开始学习mqtt。我正在使用 paho.mqtt 作为 python 并使用下面的函数记录订阅者

def on_log(client, userdata, level, buff): 
    print(buff)

我看到这个正在打印出来

Sending PUBREC (Mid: 4)
Received PUBREL (Mid: 4)
Sending PUBCOMP (Mid: 4)

随着我发送的消息越来越多,Mid 之后的数字不断增加。我尝试切换到 qos=0 并且它不再出现。所以我假设它与 qos 2 如何只发送一次数据有关。

显示的数字到底是多少? mid 之后的数字一直在增加是不是很糟糕? 如果是这样,我怎样才能阻止数字无限制地不断增加?

您看到的 Mid 是“消息标识符”(MQTT 3.1 and earlier) or "Packet Identifier"(MQTT 3.1.1 and later)。

这是一个唯一标识消息的数字(在传递握手过程中)。你看到了:

Sending PUBREC (Mid: 4)
Received PUBREL (Mid: 4)
Sending PUBCOMP (Mid: 4)

这表示在 QOS 2 上收到了 ID 为 4 的消息(发生在您显示的日志位之前)。从那里握手是:

  • 接收者(你)发送一个PUBREC
  • 当发布者收到 PUBREC 时,它会发送一个 PUBREL
  • 最终在收到 PUBREL 后,接收方发送 PUBCOMP 以完成交易。

每个数据包中都需要 ID,以便代理可以判断确认与什么消息相关(参见 this answer for more info). The above is explained well in this article

QOS 0 消息即发即忘,因此没有确认,因此不需要消息 ID。 spec states“如果 QoS 值设置为 0,则 PUBLISH 数据包不得包含数据包标识符。”。这就是为什么你在设置qos=0.

时没有看到它的原因

QOS 1 消息确实包含一个 ID,但握手更简单(接收方只发送一个 PUBACK)。

为了提供唯一标识符,Paho Python client 从 1 开始,然后在每次需要 ID 时增加它(当它达到 65536 时循环回到 1)。从理论上讲,这可能会导致冲突,但您不太可能在任何时候都有 65536 条消息在传输中(但这可能发生;特别是当连接断开并且消息正在排队时)。

所以您所看到的是预期的,而不是您需要尝试和修复的东西!