MQTTでのクライアント/サーバー接続の確立に関する混乱


19

仕様によると、サーバーへの接続を確立するのは常にクライアントです。

クライアント:

MQTTを使用するプログラムまたはデバイス。クライアントは常にサーバーへのネットワーク接続を確立します。できる

  • 他のクライアントが興味を持っている可能性があるアプリケーションメッセージを公開します。

  • それが受信することに関心があることを要求アプリケーションメッセージを購読します。

  • アプリケーションメッセージのリクエストを削除するには、登録を解除します。

  • サーバーから切断します。

このクライアントがアプリケーションメッセージをサブスクライブする場合、サーバーはこれらのメッセージをこの特定のクライアントに転送する必要があります。

サーバ:

アプリケーションメッセージを発行するクライアントとサブスクリプションを作成したクライアントとの間の仲介として機能するプログラムまたはデバイス。サーバー

  • クライアントからのネットワーク接続を受け入れます。

  • クライアントによって発行されたアプリケーションメッセージを受け入れます。

  • クライアントからのサブスクライブおよびサブスクライブ解除リクエストを処理します。

  • クライアントのサブスクリプションと一致して転送したアプリケーション・メッセージ

これは、クライアントがサブスクライブした場合、ほとんどの時間にデータフローがなくても、サブスクリプションが有効な間、サーバーに接続されたままになることを意味しますか?

クライアントがサブスクリプション後に切断した場合、接続を確立するのはクライアントであるため、サーバーはメッセージを転送できないため、この結論に達します。しかし、それは、それを再確立したときに知ることができません。

回答:


11

これは、クライアントがサブスクライブした場合、ほとんどの時間データフローがなくても、サブスクリプションが有効な間、クライアントはサーバーに接続されたままになることを意味しますか?

はい。接続が確立されると、クライアントはメッセージを待機しますが、キープアライブ値に基づいて定期的にサーバーにPINGメッセージを送信します。サーバーがPINGメッセージを受信しないと、サーバーが切断される場合があります。

サブスクリプション後にクライアントが切断された場合、サーバーは接続を確立する必要があるため、サーバーにメッセージを転送できません。

クライアントが切断された場合、はい、メッセージを受信しませんが、MQTTにはこれを回避する機能があります。

クライアントが「クリーンセッション」フラグをfalseに設定してサーバーに接続すると、サーバーはそのクライアントIDのサブスクリプションを記憶します。クライアントが再接続すると、サーバーが記憶しているため、再サブスクライブする必要はありません。

さらに、QoSレベル1または2を使用してサブスクライブできます。これらのQoSレベルでは、サーバーはメッセージを保存し、クライアントが再接続するのを待ってから送信します。これにより、クライアントが切断および再接続しても、公開されたすべてのメッセージを受信します。

このサイトには、MQTTプロトコルを説明する優れたリソースがあります。


9

これは、クライアントがサブスクライブした場合、ほとんどの時間データフローがなくても、サブスクリプションが有効な間、クライアントはサーバーに接続されたままになることを意味しますか?

はい、クライアントはメッセージを待ちます。

...クライアントがサブスクリプション後に切断した場合、サーバーはメッセージを転送できません

切断を管理する必要があります(特にバッテリー駆動のデバイスの場合)。これは、MQTT の「最後の遺言」機能を使用して実行できます。デバイスが切断されると、最後のメッセージが送信されます。


1

接続とセッションを区別する必要があります。

すべてはセッションによって定義されます。MQTT接続が初めてブローカーに許可されると、ブローカーは通常、client-id接続パラメーターに基づいて、この接続のセッションを作成します。

接続中のMQTT 3.1.1プロトコル(現在、ほとんどのクライアント/ブローカーのデフォルト)では、clean = trueまたはclean = falseフラグを指定できます。clean = trueの場合、ブローカーは新しいセッションを自動的に作成し、接続が切断または閉じられたときに閉じます。clean = falseの場合、ブローカはセッションを維持し、クライアントが切断された場合でもイベントを(ある種のセッションストレージに)配信します。clean = falseセッションを許可するかどうか、およびそのようなセッションの最大ttlはブローカーの実装に依存します。

MQTT 5.0プロトコル(非常に新しいですが、見通し)では、クライアント側からセッションttlを指定することも、接続が確立された後に変更することもできます。これは、不安定なWAN接続(ほとんどがIoT)または説明したようなステートフル接続に非常に役立ちます。

現時点では、クライアントの観点から見たMQTT 5.0プロトコルは、pythonでgmqttを使用し、javascriptでmqtt.jsを使用できます。

弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.