Fubo Docs
  • 概要
    • MQTT: IoTメッセージングの標準
    • MQTT 仕様
    • 初心者ガイド
  • チュートリアル
    • Node.js MQTT クライアントガイド
    • MQTTブローカーに接続する
    • MQTTメッセージの公開
    • MQTTメッセージの購読
    • 受信メッセージ
  • 高度なトピック
    • セッションとQoS
    • MQTT セキュリティメカニズム
    • MQTT 保持メッセージ
Powered by GitBook
On this page
  • 例の概要と目標
  • Pythonクライアント設定
  • テスト1
  • 試験 2
  • テスト 3
  • テスト4
  • テスト 5
  • クリーンセッションとクライアントID
  • 一般的な質問と回答
  • 要約
  1. 高度なトピック

セッションとQoS

クライアントがブローカーに接続するとき、それは次のいずれかを使用して接続できます

  • 非永続的な接続(クリーンセッション)または

  • 持続的な接続

非永続的な接続では、ブローカーはクライアントのサブスクリプション情報や未配信メッセージを保存しません。

このモードは、クライアントがメッセージを公開するだけの場合に理想的です。

持続的な接続を使用して耐久性のあるクライアントとして接続することもできます

このモードでは、ブローカーはクライアントのサブスクリプション情報と未配信メッセージを保存します。

ブローカーがクライアントのセッション情報を保存するためには、クライアントIDを使用する必要があります。

注意:クライアントに配信されたメッセージはブローカーから削除されます。メールメッセージが保存されるようには保存されません。

クライアントがブローカーに接続する際、永続的な接続が必要かどうかを示すために、フラグ(clean_sessionフラグ)を使用します。

しかし、サービスの品質や加入者と発行者の影響により、すべてのメッセージが配信用に保存されるわけではないことを理解することが重要です。

この例では、clean_sessionフラグと品質保証設定がメッセージ配信に与える影響を見ていきます。

例の概要と目標

この例では、2つのクライアント接続を作成するPythonスクリプトを使用します。

一方の接続がトピックを購読し、もう一方の接続がそのトピックに対して公開します。

目的は、購読者が何らかの理由で接続が切断された場合に公開されたメッセージに何が起こるかを確認することであり、 clean_session フラグとQOS 設定がメッセージ配信にどのように影響するかを見ることです。

基本的なプロセス

  1. クライアントをclean_sessionフラグを適切に設定して初期化します

  2. トピックをQOS 設定で購読する

  3. 切断します。

  4. クライアントがサブスクライブしたトピックにQOSを設定して公開します。

  5. クライアントを再接続

  6. 受信したメッセージをメモしてください

Pythonクライアント設定

クリーンセッションフラグは、4つのオプショナルパラメーターを取るクライアントコンストラクターで設定されます。デフォルト値は以下の通りです:

Client(client_id=””, clean_session=True, userdata=None, protocol=MQTTv311, transport=”tcp”)

スクリプトでクライアントインスタンスを作成するには:

client= paho.Client("Python1",False) #create client object persistent connection

翻訳テキスト:

client= paho.Client("Python1",True) #create client object clean seesion

テスト1

  • clean_session = True,

  • 公開と購読のデフォルトQOS(サービス品質)は0です

予想される結果:ブローカーはメッセージを保存すべきではないため、メッセージは受信されません。

実際の結果:ブローカーがメッセージを保存していなかったため、再接続時にメッセージは受信されませんでした。

スクリーンショット:

試験 2

  • clean_session = False,

  • 公開と購読のデフォルトQOS(サービス品質)は0です

予想される結果:メッセージが受信される。

実際の結果:再接続時にメッセージは受信されませんでした

コメント 重要なのは、clean_sessionフラグをFalseに設定するだけでなく、QOSを1 以上でパブリッシュおよびサブスクライブする必要があることです。

しかし、サブスクリプション情報はブローカーによって記憶されているため、クライアントは再度サブスクリプションする必要はありません。

スクリーンショット:

テスト 3

  • clean_session = True, 翻訳テキスト:

  • 公開と購読 QoS(品質保証)= 1

再接続時にメッセージが受信されないことが予想されます。

実際の結果:clean_sessionフラグがtrueの場合、再接続時にメッセージは受信されませんでした。

スクリーンショット

テスト4

  • clean_session = False,

  • 公開と購読 QoS(品質保証)= 1

予想される結果:再接続時にメッセージを受信すること。実際の結果:再接続時にメッセージを受信しました。

コメントクリーンセッションフラグはfalseで、公開と購読のQOSは0より大きいです。

テスト 5

  • clean_session = False,

  • 送信 QOS(品質保証)= 0 と受信 QOS(品質保証)= 1

予惜結果:? 実際の結果:再接続時にメッセージが受信されない

コメントクリーンセッションフラグはfalseですが、公開時のQOSは0より大きくありません

以下の表は、QOS、クリーンセッションフラグ、および保持メッセージフラグが受信されるメッセージにどのように影響するかを示す要約です。

デモスクリプト

クリーンセッションとクライアントID

永続的な接続では、接続の詳細がクライアントIDに対して保存されるため、永続的な接続(クリーンセッションがFalse)を使用する場合、ランダムなクライアントIDを使用することはできません。

一般的な質問と回答

Q: ブローカーはどれくらいのメッセージを保存しますか?

  • A: これはブローカーの設定です。mosquittoブローカーのデフォルトは100です - 設定はmax_queued_messagesのカウントです。

Q: クライアント接続を非永続的にリセットするにはどうすればいいですか?

  • A: 再接続するとセッションがクリーンに設定されます(True)

要約

MQTTは、電子メールのようなサービスと同じ方法でメッセージを保存しませんが、特定の状況下ではメッセージを保存します。

発行者と購読者のQOSによって、それらが保存されるかどうかが決まります。

しかし、購読者に受信され、認識されると、ブローカーはクリーンセッションとQOS 設定に関係なく、それらを直ちに削除します。

Previous受信メッセージNextMQTT セキュリティメカニズム

Last updated 12 months ago