2

这更像是一个通用问题,但是在不同的客户端或协议版本甚至服务器版本中可能会有不同的处理方式。

所以我在这里说的是 QOS 2 级订阅。在这种情况下,数据包按顺序处理。并且既然有一个确认协议,这意味着在第一个消息被确认之前无法处理下一个消息?或者它的订购只为接收而维持,而不是为了确认?

如果通过确认施加背压,这与通配符主题有什么关系?那里的“顺序”实际上只是包含主题的个体的真实概念,而不是整个通配符。这是否意味着背压也是按主题处理的,还是基于通配符订阅总数进行维护?

编辑:

所以我用 HiveMQ 和 Misquitto 做了一些测试。这两者都表现出相同的行为:只要您不在 QOS2 数据包上调用回调,整个事情就会停止响应任何事情。它甚至似乎也与通配符无关。

所以作为一个测试我有三个主题:test/1test/2test2/1

test/2消息永远不会得到确认。

我试图对这个问题进行wireshark,看看发生了什么。在我向test/2发送消息后会发生什么,无论主题如何,后续消息都不会发送给通配符订阅者。这表明通配符订阅确实并不真正关心底层主题语义。情况似乎更糟:如果我将通配符订阅分成两个单独的订阅,那么在test/1test/2上,这是完全相同的事情。任何未释放的 QOS > 0 数据包都会阻塞整个连接!所以这似乎并不表明客户端存在直接问题,但已经是与服务器相关的事情。所以我最初的问题又出现了:这是每个规范,还是这只是一个实现的好奇心?

4

1 回答 1

1

QOS 发生在发布到单个主题的单个消息的上下文中。

每当在任何通配符主题上发布消息时,通配符订阅都会导致客户端中的回调,但 QOS 机制只关心保证在单个主题上发布的单个消息的 QOS。

接收客户端订阅多个主题的事实与处理 QOS 无关。

于 2020-07-23T17:05:08.000 回答