バイ Ponlakshmi
メッセージの配信の質は、任意のプロトコルにとって非常に重要です。 MQTT は明確に定義しました サービスの質のための標準。 このブログでは、QoS 0、QoS1、QoS 2のニーズ、標準を記載しています。 使用例による明確な説明。
MQTTプロトコルIoT では、メッセージ配信の 3 つの品質 (QoS) レベルを定義します。 各MQTT QoSレベル 増加したデータ転送速度のコストが付属しています。 しかし、QoSのレベルが高いと、配送が保証されます MQTT メッセージ。 MQTT標準は、出版社と購読者の間でQoSレベルをデカップリングします。 クライアントは、帯域幅とメッセージ配信要件に基づいて異なるQoSレベルを使用することができます。 クライアント 別のQoSを別のQoSをまた使用できますMQTTのトピック出版およびサブスクリプション。
エントリーレベルまたは最初のレベルはQoSレベルです 0. 'Fire and Forget' とも呼ばれます。 このレベルは、 送信されたメッセージは、一度だけ受信者に送信されます。 メッセージ配信の保証はありません。 つまり、受信者がメッセージを受信したり、メッセージを受信できないことがあります。 クライアントまたはMQTT サーバー送らない メッセージの受領確認
QoS 0は、各メッセージが意思決定に重要でない場合に使用できます。 例えば、 学生の場所は5分ごとに正確には必要ありませんが、学生のどこにいるか決めることもあります。 このデータを使用してクラスへの出席を監視します。 生徒の場所は重要なミッションではありません インフォメーション 高レベルでは、大学キャンパス内の学生の存在は、追跡のために罰金が科されます 出席システム。
QoSの次のレベルは1です。 このレベルは、メッセージが受信者に一度送信されるようにします。 そこにあります 受諾が送信されるまで、受信者に複数の時間を配信されるメッセージの可能性 送信機(MQTTブローカーまたはパブリッシャー)への受信機(購読者またはMQTTブローカー)。 メッセージは 送信者によって保存され、受信機がPUBACKパケットを送信するために待機します。 パケット識別子は、 PUBLISH パケットを適切な PUBACK パケットと比較するための送信機。 特定の時間内で、送信者の場合 PUBACKパケットを受け取りません。MQTTのパケットDup Flag で無視する 受信機は既に元のメッセージを受け取り、PUBACKのパケットを元通りにして下さい。
QoS 1 は、各メッセージが伝送で重要であり、ネットワーク全体に必要な場合に使用されます。 積み過ぎを取り、メッセージ配達をネットワークの混雑があっても保障する容量 再送信。 ドライバーの動作が速度や加速などのパラメータに基づいて監視されると、 収集したデータは非常に重要です。 そのため、データの配信は、一度(QoS 1)) で設定する必要がありますので、 データ分析のためにすべてのデータが利用可能であること。
3番目のレベルとMQTT QoSの最高レベルは2です。 品質レベル サービス このレベルは、受信者が各メッセージを一度だけ受け取るようにします。 これは最も安全な品質です 送信者と受信者の間の2つの応答フローがメッセージ保証を提供します。 ザ・オブ・ザ・ メッセージの配信は、送信者と受信者がパケット識別子を使用して整理されます。 ネイティブのPUBLISHメッセージ。 送信者は、QoS 2 PUBLISHパケットを受信機に公開します。 それから受取人 公開メッセージを適切に処理し、PUBRECパケットをPUBRECパケットに送信することにより、PUBLISHパケットを承認 出版社。 出版社がPUBRECを受けていない場合は、DUPフラグでパケットを送信します。 認定を受ける。
出版社がPUBRECパケットを受信したら、保存してPUBRELパケットに返信します。 お問い合わせ このステージ、 元の公開メッセージは、送信元データベースで不要で、いかなるリスクもなく廃棄できます。 ザ・オブ・ザ・ パケット識別子は、パブリッシャーがPUBLISHパケットを適切なPUBRECとPUBRELにペアリングするために使用されます パケット。
受信機は、後に同じパケット識別子を持つPUBCOMPパケットで送信者に応答します お問い合わせ PUBRELを受け取りました。 受信機は、PUBCOMPを送ると同時にデータ処理を完了できます。 送信者 QoS 2フロー全体が完了すると、配送の確認が行われます。
QoS 2は、配送が非常に重要であるミッションクリティカル機能のために使用すべきである タイム。 時間に関してデータの関係が非常にある忍耐強い監視システムのため 心臓のビート、呼吸、SPo2、等のような患者のすべての重要なメトリックのために、それは使用することをお勧めします MQTT QoSの最高レベルは、完全かつタイムリーなデータデリバリーを実現します。
公開されたメッセージに起因するサービスの品質は、サーバーに接続された2つのクライアント間または ブローカー、エンドツーエンドではありません。 そのため、クライアント(subscriber)が受け取るメッセージのQoSレベルは 投稿されたメッセージのQoSレベルと購読されたトピックのQoSレベルによって決定されます。 要するに、 受け取ったメッセージの最終QoSは、クライアントの公開とサブスクライブのQoSに依存します。
ブローカーに接続すると、サブスクライブクライアントはQoSでブローカーを指示します 属性メッセージへの 必要なQoS属性でメッセージを公開します。
次の表は、MQTTクライアントの末尾にデータを受信するQoSレベルの詳細なスキーマを提供します。 Bevywise では同じを使用してビルドします。信頼できるMQTT ブローカーQoSレベルに対応
投稿されたメッセージのQoS | 会員メッセージのQoS | 決勝QoS |
---|---|---|
2 | ||
2 | 1 | 1 |
2 | 2 | 2 |
1 | ||
1 | 1 | 1 |
1 | 2 | 1 |
1 | ||
2 |
そのため、受け取ったメッセージのQosは、公開されたメッセージのQoSに似ています。
データがシグナルであるか、またはノイズが QoS レベルを使用するかどうかの決定。 お問い合わせ ヘルスケア、原子力、防衛などの重要な産業におけるデータの公開と収集を行います。 データは重要であり、すべてのメッセージのQoS 2の使用を義務付けています。 QoS 1 は QoS 2 の代わりに使用できます。 クライアントは重複したメッセージを処理できます。
MQTTクライアント(購読者)がQoS1またはQoS 2とクリーンなセッションフラグセットを接続する場合 False i.e として。MQTTの持続的な セッションお問い合わせ これらの加入者のために受け取ったデータは、ブローカーに保存され、いつ受信する必要があります これらの顧客はオンラインで来て、MQTTブローカーに接続します。
より詳細な MQTT プロトコル ドキュメントMQTTクライアントの開発お問い合わせ 独自のMQTTクライアントを作成する MQTTブローカーと接続する
プロトコルの詳細については、