我發佈的消息的Qos = 2,保留消息= false且清除會話= true。 如果我的訂閱服務器處於脫機狀態,它再次聯機時不會收到Qos 2消息。但發佈者成功獲得PUBREC和PUBCOMP當訂戶未連接時,MQTT與Qos 2發佈
-2
A
回答
2
這是MQTT協議規範,並且不依賴於您正在使用的代理。 發佈商能夠發佈給經紀商,因此它收到PUBREC和PUBCOMP,因爲發行商向經紀商的交付已完成。 在發行商和訂閱者之間,您有中間經紀人,因此有兩個合約:發行商到經紀商,經紀商到訂閱者。這些合約是相互獨立的。
然後您保留message = false和clean session = true,這意味着如果該主題沒有訂閱者,發佈的消息就會丟失。 考慮幾件事情:
- 的保留郵件標誌,可用於「儲存」在主題的最新消息,這樣,當用戶訂購,就會收到這樣的消息
- 乾淨會議標誌是使經紀人保存susbcriptions和所有消息當用戶離線
我不知道您的情況,但:
- 如果您如果您希望代理爲其所有訂閱保存所有離線訂戶的郵件,請使用clean session = false。如果您希望代理爲所有訂閱保存離線訂戶的所有郵件,請使用clean session = false。回到網上,訂戶也將能夠避免重新訂閱所有主題,因爲它們由經紀人持有。
+0
可以發佈者知道該消息已被訂閱者成功接收? –
+0
不,這不可能,它是關於「brokerd messaging」。您可以在協議之上建立一個基礎設施,以實現類似的目的:這意味着讓訂閱者向主題發佈一種ACK消息,並讓最初的製作人成爲該主題的訂閱者。但是,當然......你總是有同樣的問題,訂閱者不知道發佈者是否已收到ACK;) – ppatierno
相關問題
- 1. 瞭解MQTT用戶QoS
- 2. MQTT QoS降級
- 3. Bluemix在與Paho MQTT客戶端發佈時斷開連接
- 4. Bluemix快速入門在與Paho MQTT客戶端發佈時斷開連接
- 5. 關於MQTT PubAck與QoS等級一個
- 6. 主從與發佈 - 訂閱連接
- 7. MQTT客戶端同時發佈和訂閱
- 8. 發送qos參數以及MQTT通知
- 9. MQTT流式QoS控制
- 10. MQTT qos 2 PUBREC和PUBREL之間的超時
- 11. 將外部MQTT發佈者與NODE-RED連接
- 12. MQTT發佈/訂閱通信格式
- 13. mosquitto客戶端在發佈QoS = 2(max_inflight_messages = 1)後不再接收消息
- 14. MQTT客戶端重新用於發佈/訂閱
- 15. MQTT連接activeMQ
- 16. 連接到MQTT發生在發佈後,由於異步
- 17. 爲未知用戶發佈Shopify訂單
- 18. JSF和applicationscoped bean連接(發佈/訂閱)
- 19. ESP8266未連接到MQTT代理hivemq
- 20. docker:當連接到已發佈的端口時拒絕連接
- 21. SQL內部連接客戶與訂單
- 22. Paho(MQTT)客戶端無法連接
- 23. NetMQ訂戶與發佈的消息
- 24. 代理在QoS 1或2中持有多長時間的MQTT消息?
- 25. 在MQTT訂戶中執行操作
- 26. Meteor.js發佈和訂閱2
- 27. Socket.error:[Errno 10060]連接到MQTT代理時
- 28. 將MQTT連接到累積租戶
- 29. 如何將訂戶與reactor.core.publisher.Flux連接?
- 30. 最大MQTT連接
是什麼問題?您使用的是什麼MQTT實施/服務? – Soren
我正在使用配置單元mq websocket。 –