MQTTクライアントは、自分で作成したトピックをサブスクライブできますか？

私の理解では、クライアントが対応するトピック名で何かを発行すると、MQTTでトピックが作成されます。

トピックを構成する必要はありません。トピックを公開するだけで十分です。

ここから。

クライアントが自身のトピックをサブスクライブすることは可能ですか？仕様には制限がありませんでした。異常動作の可能性としてリストされていません：

5.4.8異常な動作の検出

サーバー実装では、クライアントの動作を監視して、潜在的なセキュリティインシデントを検出する場合があります。例えば：

• 接続試行の繰り返し
• 繰り返し認証試行
• 接続の異常終了
• トピックスキャン（多くのトピックの送信またはサブスクライブの試行）
• 配信不能メッセージの送信（トピックの購読者なし）
• 接続するがデータを送信しないクライアント

これに基づいて、私はそれが確かに可能であると思います。だから私はこの機能の使用例に興味がありますか？

なぜ標準ではそのようなメカニズムが許可されているのでしょうか？そのため、クライアントが自分のトピックにサブスクライブできるようにするだけです。

私が考えることができる1つのユースケースは、クライアントが公開されたデータを検証できるこの方法です。

はい、自分で作成したトピックにサブスクライブすることは可能です。

MQTTクライアントは、パブリッシャーとサブスクライバーの両方になることができます。MQTTの用語では、クライアントは両方を含んでいるsubscribersとpublishers。

この機能の使用例に興味がありますか？

考えられるユースケース（私が推測する）は、x-topicによって作成されたトピックにサブスクライブしている3つのクライアント（x、y、z）があるとしxます。にメッセージが公開されるたびに、x-topicそのトピックにサブスクライブしている全員がメッセージを受信します。yトピックにメッセージをパブリッシュする場合x-topic（できると思います）、xトピックを作成したにもかかわらずそのトピックにサブスクライブしない場合、メッセージを受信しません。

そのため、クライアントはトピックの元の作成者であるにもかかわらず、メッセージを受信するためにトピックにサブスクライブする必要があります。

ただし、ブローカーを媒体として使用することにより、メカニズムを制御できます。

はい。

MQTTクライアントは、クラウドまたは他のデバイスであるブローカーに接続されます。

トピックの作成のようなものはありません。メッセージの見出しとして使用されます。クライアントがトピックをサブスクライブし、そのトピックで何かを公開している場合、メッセージはブローカーを介してクライアントに再度受信されます。

優れたブローカーの例は、デバイスで実行するためのMosquittoや、クラウドベースのブローカー用のCloudMqttです。