パブリッシュ/サブスクライブパターンに基づくプロトコルは、メッシュネットワークの利点を無効にしますか？

MQTTやAMQPなどのパブリッシュ/サブスクライブパターンに基づいてモデル化されたプロトコルでは、メッセージの送受信を調整するために集中型のメッセージブローカーが必要です。IoTネットワークがスタートポロジに基づいている場合、これはそれほど問題にはなりません。すべてのメッセージがいずれにせよ中央ハブを経由する必要がありますが、メッシュネットワークの利点と、これらがどのように影響を受けるかについて考えていました。プロトコルの選択。

スレッドはじめにプレゼンテーションは、特にスレッドのメッシュネットワーク（ただし、これらは一般的に適用されるべきである）のいくつかの利点の概要を示します。

single単一障害点がない

✔自己回復

✔干渉の堅牢性

✔自己拡張型

critical重要なインフラストラクチャに十分な信頼性

後者の4つのポイントがプロトコルの選択の影響を受けるとは想像できませんが、メッセージブローカープロトコルを使用すると、メッシュネットワークの「単一障害点がない」という利点がなくなるかどうか知りたいです。

パブリッシュサブスクライブベースのプロトコルを使用すると、一般的に避けられない単一障害点が発生しますか。これが、スレッド紹介プレゼンテーションで、使用する可能性のあるプロトコルとして代わりにCoAPが提案されている理由です。

^{単一障害点を取り除くために複数のブローカーをサポートするMosquittoについてはすでに質問しましたが、これがメッシュネットワークとパブリッシュサブスクライブプロトコル間の根本的な競合であるかどうかを質問しています。}

はいといいえ。

どちらのテクノロジーも、接続を提供するさまざまなレベルに関係しています。通常、メッシュネットワーキングは、実装の範囲に応じて、レベル3または4、あるいはISO OSIモデルの両方で提供されます。ネットワーク層とトランスポート層は、メッシュネットワークの基本的な信頼性を提供します。ノードが落ちても、その信頼性は通常妨げられません。

MQTTとAMQPは、レベル7のアプリケーション層プロトコルです。したがって、これらのプロトコルは、基本的なモデルに関する限り、下位レベルの信頼性に依存しています。ただし、より低いレベルの障害に対処するためのセーフガードを実装することは、常により高いOSIレベルの特権です。たとえば、ネットワーク障害を検出した場合、アプリケーションはWi-Fiから4Gへなど、完全に異なるネットワークに切り替えることができます。スマートフォンは、Wi-Fiが設定された場所に出入りするときに常にそれを行います。

下位レベルが上位レベルの障害に対応できる可能性もあります。たとえば、OSIレベル4の負荷分散は、その背後にある障害のあるノードに対応できます。もちろん、そのためには、負荷分散やフェイルオーバーソリューションのために対処できる各ノードが同じサービスを提供できる必要があります。また、明らかに少なくとも2回は中央コンポーネントが必要です。以来、MQTT基本的に単純な複製によって可能であるべきであるトピックに基づいてルーティングアプリケーション・レベルです。これは、HiveMQを実装したMQTTクラスターソリューションの例です。

それを念頭に置いて、いいえ、ネットワークおよびトランスポートレベルの信頼性は、より高いレベルのプロトコルの選択によって否定することはできないと結論付けることができます。ただし、これはユーザーエクスペリエンスには適用されません。ユーザーにとって、下位レベルのプロトコルは単なる車両です。単一障害点のあるアプリケーション層プロトコルを使用することは、そのノードが壊れている場合、はい、ネットワークがまだ機能していても機能が壊れていることを意味します。

とにかく、アプリケーション層以上はユーザーに信頼性を提供する責任があります。メッシュネットワークは、基本のみを提供できます。

最後に考慮すべきことが1つあります。すべてのコンポーネントに冗長性がない限り、単一障害点のあるユースケースは常に存在します。ほとんどの場合、ユーザーが実際に操作するノードです。たとえばホームオートメーションでは、すべての障害のあるノードは、ユースケースを失ったことを意味します。