MQTTより簡単ですか? MQTT / UDP

このトピックに関する詳細な記事を書きたかったのですが、明らかに、手が届きません。 したがって、短いメッセージ。 MQTT / UDPという作業名でMQTTプロトコルのバージョンをプロトタイプコードとしていくつかの言語で開発および実装しました。 せっかちな人やすでにすべてを理解している人、そして明らかに、 Githubのコード



なぜ



私は数年間、自分のスマートホームシステムによってほぼ完全に制御されているアパートに住んでいます。 ライト、空調、センサー、簡単な自動化、それだけです。



この間、UDシステムの主な特性は信頼性であることがわかりました(はい、ちなみに、以前は理解していました)。



定義により、中央ノードを持つすべてのシステムは信頼できません。 ここから、中央ハブを使用せずに相互接続システムコンポーネントを取得したいという要望があります(そして、それらの多くは実際のスマートホームにあります)。



同時に、一般に、UDシステムのトラフィックは小さいという事実から進んでいます-センサーを1分に1回よりも頻繁に更新する必要はほとんどなく、残りのデータはイベントベース(ライトオン)であり、トラフィックはまったく重要ではありません。 システム内のすべてのデータの1秒ごとの更新でさえ、災害であるだけでなく、重大な問題です。



論理的な結論は、UDPブロードキャストが理想的なツールであるということです。



(はい、アパートの内部ネットワークはファイアウォールで閉じられていると思います。)



長所は何ですか:



信じられないほどシンプルな実装。 小さなメモリを備えた最小のマイクロコントローラは、UDPパケットを送信できます。 センサーの場合、UDP受信でさえ必要ありません。



非常に低いレイテンシー。 中央のハブには転送はありません。UDPパケットの配信時間は、実際には最新のシステムの最小時間です。



ハブ/ブローカーに障害の中心点はありません。 シンプルなスキームを考えてみましょう:2つの温度センサー、床暖房コントローラー、暖房バッテリーコントローラー。 MQTT / UDPを使用すると、このようなシステムの一部に障害が発生しても、システム全体に障害が発生することはありません。



ネットワークトラフィックが少ない。 どこにもありません。 TCPと確認応答はトラフィックのみを追加しますが、信頼性は追加しません。 センサーの故障は、TCP ACKの受信では機能しません。 そして、更新がないことで障害を特定します。



UDPプロトコル自体の信頼性は重要ではありません-センサーは依然として定期的にデータを更新し、カウントの消失は完全に見えません。たとえば、スイッチからのコマンドの消失は、ターゲットシステムの障害によって視覚的に確認されます。 人は何をしますか? もう一度クリックします。 ただし、これはプロトコルの適用性に関する大きな制限です。 定期的な投票に最適です。



システム構成は不要です。 ブローカー、ハブなどのアドレスを登録する必要はありません。 ただし、センサー構成はまだ必要です-センサーIDを登録する必要があります。 ただし、システムの他の部分を他のサーバーに転送する場合、応答コンポーネントの再構成は必要ありません。



このデータ交換のモデルが、ラジオチャネルやRS / 485などの自然に放送されるメディアにうまく適合することは特に興味深いです。 私はこれを試していないので、そのような環境のプロトコルを制御する必要があります。 ちなみに、ここではmodbusからCRC16を適用するのが論理的です。



マイナスも明らかです。配信の信頼性は、ネットワーク上のハードウェアとトラフィックによってのみ決定されます。敵がネットワークに侵入した場合、プロトコルはすぐに無効になります。 確かに、他の典型的なスマートホームプロトコルをハッキングするのはほんの数秒ですので、率直に言って、これはMQTT / UDPの物議を醸す欠点です。 別の明らかでないマイナスは、IPアドレスごとに最大1つのレシーバーです。



何が行われ、ソースのリポジトリにあるか:





もっと時間があったらどうしますか:





それをありがとう、リポジトリへようこそ



PS: この記事では、マルチキャストを使用した同様のアプローチについて説明します。



All Articles