MQTT：持续会话消息的优先级与保留消息
假设我有主题A和主题B。 启动我的应用程序后，在on_connect中，我正在使用QoS 2订阅这两个主题。 现在，假设我有错过了关于主题的消息b ，这些消息是在我离开时发送的，并且我保留了有关主题的消息。
订阅后，将首先处理哪些消息？
- 是否由于类型（IE持续的会话消息并保留了主题上的消息）而定义？
- 还是
on_connect决定性的订阅订单？ （我不会假设线程仅在loop_forever（）上开始检查它们，并且可能无法推定该顺序） - 还是随机的？
从我的测试中，由于主题b 的持续性会话，我收到的错过消息将首先处理。
我可以依靠这种行为吗？
PS：正如Hardillb提到的那样，行为可能是经纪人的特定于经纪人的。我正在使用蚊子。
Assuming I have topic A and topic B.
Upon starting my application, inside on_connect, I am subscribing to both topics with QOS 2. Then I start the thread with loop_forever().
Now, lets assume I have missed messages on topic B which were sent while I was gone and I have retained messages on topic A.
Upon subscribing, which messages will be processed first?
- Is it defined due to the type (i.e. persistent session messages and retained messages on a topic)?
- Or is the subscription order in
on_connectdecisive? (which I would not assume as the thread starts checking them uponloop_forever()only and the order might not be presumed) - Or is it random?
From my tests, it seems the missed messages I get due to the persistent session from topic B will be processed first.
Can I rely on that behaviour?
PS: As hardillb mentioned that behaviour might be broker specific. I am using Mosquitto.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
首先，您的模型有点错了，客户没有检查任何内容，消息传递完全由经纪人驱动。所有
loop_forever（）thread is to is to and the Broker的入站消息（如果需要，则需要对高QoS消息的响应）。另外，如果您有持续的会话，则不需要重新订阅主题，因为订阅仍应附加在经纪人中的会话中，当客户端重新连接时，该会话将恢复（具有相同的客户端ID和清洁错误）。
关于哪个将首先保留或排队的梅斯，我认为 spec 实际上定义了哪个订购代理应发送排队消息与保留消息，这意味着这很可能是代理实施的。
First your model is a little wrong, the client doesn't check for anything, message delivery is entirely driven by the broker. All the
loop_forever()thread does is handle the inbound messages from the broker (and if needed the response for high QOS messages).Also if you have a persistent session, then there should be no need to re-subscribe to the topics as the subscription should still be attached to the session in the broker, which will be resumed when the client reconnects (with the same client ID and cleanSession false).
As to which will be delivered first retained or queued mesages, I don't think the spec actually defines which order the broker should send queued messages vs retained messages, which means it may well be broker implementation specific.