ユーザーから発信されたMQTT Publishイベントと、ブロードキャストのみを目的とした内部メッセージとを区別する方法

Question

mosquitto mqtt clientを使用しています。

たとえば、トピックを公開して購読するユーザーがいます。トピックは実際にREsTエンドポイントと相関しています。

シナリオ1（典型的なパブ/サブ使用）

1. UserAがトピック/デバイス/ 123 /メタ
2. ユーザーBに加入するために、いくつかのデータを公開トピック/デバイス/ 123 /メタ
   • 定義により、この公開はサブスクライバにブロードキャストされます
   • トピック/デバイス/ 123 /メタのペイロードを保存する方法を知っている/ devices /＃に登録されたスクリプトがあります公開されたデータを受信します。このデータはデータベースに保存されます。

シナリオ2

1. 誰かがRESTインターフェースを介してデータ/デバイス/ 123 /メタを更新する（または直接DBの更新、鍵は、MQTT公開しない場合）。
   • データベースは、すべての加入者がペイロードとしてアップデートを取得するようにシナリオ2は私がラップしようとしているものです

MQTTブローカーに送信され

がメッセージをパブリッシュ更新され、私の周りに頭を下げる。これは厄介なフィードバックループを作ります。内部メッセージがブロードキャストされると、ユーザーからのパブリッシュ・イベントを処理するスクリプトは、サード・パーティーのユーザーから発生したパブリッシュ・イベントと、（データを保存しないで）一部のデータをブロードキャストするだけの内部パブリッシュ・イベントを区別できません。

どうすればよいですか？ MQTTメッセージは非常に単純化されており、私はロジックをベースにすることはできません。私は何とか起源を使って探索しようとしていますが、これまでの運はありません。私はプラグインを書くことができることを認識していますが、これは蚊のため​​のかなりの仕事です。

Answer 1

純粋なMQTTプロトコル・レベルでメッセージがサブスクライバーから発信された場所を区別する方法はありません。 pub/subプロトコルのポイントの1つは、出版社と加入者を切り離すことです。

これを実行するもっとも移植可能な方法は、メッセージが実際のデバイス以外から発信されたことを示すために実際のメッセージペイロードにフラグを追加することです。

また、結果としてメッセージが公開されていると仮定すると、着信メッセージが実際にデータベースの格納値を変更した場合、データベースのトリガーがトリガーチェックを行い、受信メッセージがDBの既存の状態と一致する場合、それを再発行する。

Mosquittoのプラグインメカニズムは、現在、認証および認可ソリューションの作成にのみ使用されていますが、JavaScript moscaまたはJava HiveMQブローカーは、必要な機能を備えたプラグインをサポートしています。