1

私は moquette mqtt ブローカーを使用しており、実装と MQTT ブローカーを理解しようとしています。個人的なプロジェクトのためにブローカーにいくつかの変更を加えたいと思っています。

デバイスが PUBLISH メッセージをブローカーに送信し、ブローカーがサブスクライバーにメッセージを配信できない場合にどうなるか知りたいです。プロトコルは、PUBACK がパブリッシャーに送り返されることを示しています。moquette のソース コードでは、この PUBACK はメッセージをサブスクライバーに転送した後に送信されるようです。

sendPubAck() 関数をコメントアウトして、メッセージが正常に発行されなかったことをシミュレートしたので、パブリッシャーがメッセージを再度発行すると想定しました。ただし、受信メッセージ ハンドラー関数の横に print ステートメントを追加すると、パブリッシャーからブローカーに定期的に送信される PINGREQ メッセージしか表示されません。パブリッシュ メッセージが表示されません。

私の質問は次のとおりです。クライアント デバイスは、メッセージを再発行するタイミングを正確にどのように決定しますか? sendPubAck() 関数をコメントアウトしても、パブリッシャーはメッセージを再送信しないようです。

4

1 に答える 1

2

2 つの選択肢があります。まず、メッセージ タイムアウト パラメーターを追加して、PUBACK が受信されない場合に PUBLISH の再送信をトリガーすることができます。次に、再接続時にのみ PUBLISH を再送信できます。

2番目の選択肢が最良の選択肢だと思います。この理由は、ブローカー (または、もちろん、通信の方向に応じてクライアント) が応答していない理由が考えられます。

  1. バグのあるブローカーを持つことができますが、これは実際に作成したものです
  2. ネットワーク障害が発生した可能性があります (接続が失われたが検出されない)。
  3. ブローカーが過負荷になっている可能性があります。

最初のケースでは、ブローカーを修正する以外にできることはありません。2 番目のケースでは、クライアントは再接続時にパブリッシュを再試行する必要があります。3 番目のケースでは、重複した PUBLISH を送信してもブローカーは応答しません。さらに過負荷になるだけです。

ブローカは、PUBACK を発行クライアントに送信する前に、購読クライアントの応答を待機してはならないことに注意してください。

于 2015-06-26T06:19:00.413 に答える