MQTT 用のクライアントを開発しているテスト プログラムで、この問題が発生しました。トピックを購読しています。その後、サーバーからクライアントへの「公開」メッセージを待ちます。
(パブリッシュ メッセージの) 良好な recv の後、または recv タイムアウトの後、mqtt PINGREQ をサーバーに送信します。
A PINGREQ の後、PINGRESP を待ちます。その後、PUBLISH メッセージを待っている場合と同様に、recv を呼び出します。
こんな流れなら
Client -> PINGREQ
Server -> PUBLISH
Server -> PINGRESP
サーバー パブリッシュ メッセージが失われました。これを解決するには？QOS 0 で MQTT を使用しています。このレベルの QOS でこの問題を解決するのは理にかなっていますか、それとも QOS1 でこのケースをチェックするのが賢明ですか?
I think you've got things a bit confused. PINGREQ/PINGRESP are used when there isn't any other network traffic passing between the client and server, in order to let both the client and server know if the connection drops.
Your client should keep track of the when the last outgoing or incoming communication with the server was, and send a PINGREQ if it is going to exceed the keepalive timer it set with its CONNECT command. The server will disconnect the client at 1.5*keepalive if no communication is received. The client should assume the server has been disconnected if it does not receive a PINGRESP in response to its PINGREQ within keepalive of sending the PINGREQ.
The QoS level isn't that important, you have to ensure the keepalive timeout is maintained regardless.
It also occurs to me that it sounds like you're using blocking network calls - it might be best to move to non-blocking if you can to get more flexibility.