サーチ…


前書き

このプロトコルは、TCP / IPを介して、または順序づけられた無損失の双方向接続を提供する他のネットワークプロトコルを介して実行されます。

MQTTの単純なパブリック/サブスクライブ・モデル

その主な機能は次のとおりです。

  • 1対多のメッセージの配信とアプリケーションのデカップリングを提供するパブリッシュ/サブスクライブ・メッセージ・パターンの使用。

  • ペイロードの内容に依存しないメッセージングトランスポート。メッセージ配信の3つのサービス品質

  • 小さなトランスポートオーバーヘッドとプロトコル交換を最小限に抑えてネットワークトラフィックを削減

ここに画像の説明を入力

一般に、2種類のメッセージングサービスがあります。

  • キュー(1対1接続)

  • トピック(1対1/1対多)

MQTTは信頼できるキューをサポートしていませんが、MQTTはトピックをサポートしています(デフォルトではトピックは信頼できませんが、MQTTの機能とメソッドを使用して信頼性を高めることができます)。

トピックとキューの違い

キュー:

  • ポイントツーポイントモデル
  • 1人の消費者だけがメッセージを受け取る
  • メッセージは送信された順序で配信する必要があります
  • キューは、各メッセージが1回だけ処理されることを保証します。
  • キューは、コンシューマまたはJMSクライアントが誰であるかを認識します。目的地は既知です。
  • JMSクライアント(コンシューマ)は、メッセージを受信または読み取るために常にキューにアクティブまたは接続する必要はありません。
  • 正常に処理されたすべてのメッセージは、コンシューマによって認識されます。

トピック:

  • パブリッシュ/サブスクライブモデル

  • 複数のクライアントがメッセージを購読する

  • 保証メッセージは送信された順序で配信される必要はありません

  • 各メッセージが一度だけ処理されるという保証はありません。これはモデルから感知することができるので

  • トピックが複数のサブスクライバを持っていて、トピックがすべてのサブスクライバを知らない可能性があります。目的地は不明です

  • サブスクリプションが永続サブスクリプションでない限り、サブスクライバ/クライアントはプロデューサによってメッセージが生成されたときにアクティブにする必要があります。

  • いいえ、正常に処理されたすべてのメッセージは、コンシューマ/サブスクライバによって確認応答されません。

MQTTを使用してトピックの短所を減らすことができます。トピックは信頼性が高く、MQTT機能の重複を制御できます



Modified text is an extract of the original Stack Overflow Documentation
ライセンスを受けた CC BY-SA 3.0
所属していない Stack Overflow