MQTT (Paho) 中的訂閱會發生沖突嗎？

Question

我對 Paho 中的訂閱以及應用程序如何管理不同的主題（允許使用通配符）有疑問。 我們很感興趣，因為我們提供了一個層來管理所有這些東西，以簡化開發人員的生活，因此如果需要，我們以后可以在幕后使用非 MQTT 發布/訂閱。

一個例子可能是最好的解釋方式。 假設我們的程序中有兩個獨立的模塊：

• get_all_info()短時間訂閱主題fleet/vehicle-N/#以獲取特定車輛N的所有信息。
• speed_mon()只對所有車輛的速度感興趣，在程序運行期間訂閱fleet/+/speed 。

考慮序列^(a) ：

• speed_mon()訂閱fleet/+/speed 。
• get_all_info()訂閱fleet/vehicle-17/#並獲取信息。
• get_all_info()取消訂閱fleet/vehicle-17/# 。

第三次手術會影響第一次嗎？ 換句話說，我們還會收到主題fleet/vehicle-17/speed消息嗎？

如果取消訂閱是對特定訂閱的簡單撤銷，它將僅禁用在第二個要點中創建的訂閱。

如果它使用過濾器禁用所有匹配的訂閱（在通配符的意義上），它也會影響第一個訂閱。

---

^(a)現在忽略這樣一個事實，即我們最好在程序運行期間使用get_all_info()訂閱fleet/#並且從不取消訂閱，而只是將消息緩存到本地存儲中。 這是一個人為的例子。 我們無法控制客戶如何使用我們的層。

Answer 1

我相信 MQTT 規范對此非常清楚。 v3和v5文本相似； v3 狀態：

UNSUBSCRIBE 數據包中提供的主題過濾器（無論它們是否包含通配符）必須逐個字符地與服務器為客戶端保存的當前主題過濾器集進行比較。 如果任何過濾器完全匹配，則刪除其擁有的訂閱，否則不會發生額外處理 [MQTT-3.10.4-1]。

所以這是一個字符一個字符的比較； 取消訂閱fleet/vehicle-17/#不會影響訂閱fleet/+/speed 。

請注意，在將傳入消息映射到回調時，某些庫可能無法正確實現這一點（go 庫曾經有過這個錯誤）。

也許一個更有趣的問題是（你沒有問這個但它可能會產生影響）：

如果我同時訂閱了fleet/+/speed和fleet/vehicle-17/# ，我將獲得關於fleet/vehicle-17/speed主題的多份消息副本。

這里的行為更受 v3 ( spec ) 中的實現細節的約束，但由於引入了訂閱標識符 ( spec )，v5 中對其進行了明確定義。