MQTT從發佈和mqtt ping recv C

我有這個問題，在測試程序中，我正在開發MQTT客戶端，我訂閱了一個主題，之後，我等待「發佈「消息從服務器到我的客戶端。MQTT從發佈和mqtt ping recv C

一個好的recv（發佈消息）或recv超時後，我發送一個mqtt PINGREQ到服務器。

A PINGREQ後，我要等待PINGRESP，然後我打電話給recv，就像我在等待PUBLISH消息一樣。

如果流程是這樣的：

Client -> PINGREQ 
Server -> PUBLISH 
Server -> PINGRESP

不是服務器發佈消息丟失了。如何解決這個問題？我在QOS 0上使用MQTT，在這個QOS級別解決這個問題是合理的，或者在QOS1上檢查這種情況很明智嗎？

來源

2013-04-08 andrea

我想你已經有些困惑了。 PINGREQ/PINGRESP用於在客戶端和服務器之間沒有任何其他網絡流量通過時，爲了讓客戶端和服務器知道連接是否斷開，使用PINGREQ/PINGRESP。

您的客戶端應該跟蹤最後一次與服務器的傳出或傳入通信的時間，並且如果它要超過通過其CONNECT命令設置的Keepalive計時器，則發送PINGREQ。如果未收到通信，服務器將以1.5 *保持連接斷開客戶端連接。如果客戶端在發送PINGREQ的過程中沒有收到響應其PINGREQ的PINGRESP，則客戶端應假定服務器已斷開連接。

QoS級別並不重要，您必須確保Keepalive超時保持不變。

對我來說，聽起來好像你正在使用阻塞網絡呼叫 - 如果你能獲得更多的靈活性，最好轉移到非阻塞。

來源

2013-04-08 21:15:03 ralight

謝謝，我正在轉移到非阻塞呼叫。通過這種方式，我的客戶可以接收PINGREQ，並且有一個PUBLISH傳入，對嗎？這是好處嗎？ – andrea 2013-04-10 20:42:09

我現在正在測試發佈所有數據到達後，在接收期間沒有發現更多數據，服務器似乎關閉連接。似乎在從服務器發佈到客戶端時，計時器未被重置。 – andrea 2013-04-11 11:22:20

非阻塞呼叫具有顯着的優勢，即您在呼叫recv（）後不必等待傳入數據到達。 – ralight 2013-04-11 14:08:54

MQTT從發佈和mqtt ping recv C

回答

相關問題