Qt MQTT の概要

Qt MQTT では、MQ テレメトリ・トランスポート（MQTT）プロトコルで通信できるアプリケーションやデバイスを作成できます。MQTT プロトコル仕様に完全に準拠しています。

パブリッシュとサブスクライブ

MQTTは、パブリッシュ＆サブスクライブモデルで動作するマシン間接続プロトコルです。MQTTクライアントは、ブローカーとも呼ばれるMQTTサーバーへのネットワーク接続を作成するためにMQTTを使用するプログラムまたはデバイスです。接続が作成されると、クライアントはブローカーにメッセージを送信できる。他のクライアントは、クライアントが送信した特定のトピックに関する通知を購読することができます。

例えば、クライアント2が トピックAに関するメッセージを購読している場合、クライアント1がそのトピックに関するメッセージを送信すると、通知を受信する。クライアント 3がトピック Aとトピック B を購読している場合、その両方のトピック上のメッセージに関する通知を受信する。

Qt MQTT は、ブローカーを含まないクライアント・ソリューションである。特に、組み込み機器向けの遠隔測定アプリケーションの開発に適しています。ただし、Qt MQTT には外部依存関係がないため、実装されたクライアントはサポートされているすべての Qt プラットフォームで実行できます。

トピック

トピックは階層ツリー構造で保存される。この規格では、ツリーをどのように設計すべきかは規定されておらず、定義済みの階層セットも提供されていません。プロジェクトが必要とする階層を自由に設計することができます。以下はトピック階層の例で、activeはすべてのアクティブなセンサーを意味し、houseとgarageは個別のセンサーを意味します：

sensors/active
sensors/house/temperature
sensors/house/bedroom/light
sensors/house/livingroom/light
sensors/garage/temperature
sensors/garage/light

ワイルドカードを使用したトピックの購読

クライアントがトピックを購読するとき、ハッシュマーク (#) とプラス記号 (+) をワイルドカードとして使用できます。ハッシュマークは、クライアントがトピックとそのサブトピックに関するすべてのメッセージの通知を受信したいことを示します。例えば、クライアントがsensors/house/# を購読すると、家センサーに関するすべてのメッセージを受信する。

プラス記号は、一致するサブトピックを探すときに、ツリー上のブランチをスキップできることを示す。例えば、クライアントがsensors/+/temperature を購読すると、どのセンサーが送信したかに関係なく、温度に関するメッセージを受信する。複数のプラス記号を使うと、複数のブランチをスキップすることができる。例えば、house/+/+/temperatureは、一軒家のすべてのアパートのすべての部屋の温度に関するメッセージを受信するために使用できます。

共有サブスクリプション

共有サブスクリプションは、1 つのトピックフィルタに対するサブスクライバのプールを記述する。すべてのサブスクライバがメッセージを受信する代わりに、1 人のサブスクライバのみがメッセージを受信します。これにより、複数のクライアントでのロードバランシングが可能になります。共有サブスクリプションの書式は以下の通りである：

$share/{sharename}/{topicfilter}

例えば、クライアント1とクライアント2が sensors/house/temperatureというトピックに対するサブスクリプションを共有する場合、サブスクライブするトピックフィルターは以下のようになる：

$share/poolAB/sensors/house/temperature

サーバーがどの順番でメッセージを配布するかは定義されていません。これはサーバー固有のオプションである。

サーバが共有サブスクリプションをサポートしているかどうかを確認するには、QMqttServerConnectionProperties::sharedSubscriptionSupported() も参照してください。

トピックのエイリアス

トピックをツリーで構造化すると、データ・チャネルを分離し、情報の論理的な順序を示すのに役立ちます。ただし、この場合、メッセージの発行時に非常に長いトピック名が使用され、各メッセージのサイズが大きくなる可能性があります。

MQTT 5.0プロトコル・バージョンでは、これを回避するためにトピック・エイリアスが導入された。トピック文字列の代わりに、整数値が送信される。クライアントとサーバー間の初期マッピングを作成するには、トピック文字列とエイリアスの両方をメッセージの一部にする必要がある。その後は、空のトピックを持つIDだけが使われる。

このマッピングは、別のトピック文字列を持つトピック・エイリアスを使うことで、いつでも変更することができる。このマッピングは、サーバーから他のクライアントへの接続など、他の接続には必ずしも適用されないことに注意してください。各接続では、このマッピングを手動で作成する必要があります。

Qt MQTT には、データ転送速度を抑えるための自動化メカニズムが用意されている。QMqttClient が接続を作成した後、サーバーがサポートするトピックエイリアスに関する情報が保存されます。その後、利用可能なエイリアスがすべて使用されるまで、トピックエイリアスがメッセージの発行順に使用される。ユーザは、公開時にQMqttPublishProperties::setTopicAlias() を使用することで、常にこのマッピングを変更することができる。

QMqttClient がトピックを購読すると、クライアントが設定したQMqttConnectionProperties::maximumTopicAlias() の値に応じて、サーバーもトピック・エイリアスを使用できる。クライアントは自動的にトピックエイリアスをマッピングし、完全なトピック文字列を含むメッセージを透過的にユーザーに転送します。

セキュリティ

クライアントとブローカー間の接続は、ユーザー名とパスワードを使用する組み込みの認証システムによって保護されています。メッセージはトランスポート層で SSL/TLS を使用して暗号化される。暗号化された MQTT メッセージ用の標準ポート番号は 8883 です。

サービス品質

メッセージのサービス品質（QoS）レベルは以下のように定義されている：

• At most once（0）は、動作環境の最善の努力に従ってメッセージが配信されることを意味するため、メッセージの損失が発生する可能性がある。このレベルは、例えば、個々の読み取り値が失われたとしても、次の読み取り値がすぐに発行されるため、問題にはならないような環境センサーデータで使用することができる。
• 少なくとも1回（1）は、メッセージは確実に届くが、重複が発生する可能性があることを意味する。
• Exactly once (2)は、メッセージが一度だけ確実に届くことを意味する。このレベルは、例えば、メッセージの重複や紛失によって誤った料金が適用される可能性がある課金システムで使用される可能性がある。

遺言メッセージ

遺言 状とも呼ばれる遺言状メッセージは、クライアントから送信され、ブローカーの場所に保存されるメッセージです。クライアントとブローカー間の接続が予期せぬ方法で切断された場合、遺言メッセージは遺言トピックの購読者に転送されます。

ウィル・メッセージは接続の段階で指定されなければなりません。したがって、QMqttClient::connectToHost() またはQMqttClient::connectToHostEncrypted() を呼び出す前にそれらを設定する必要があります。ウィル・メッセージは通常のメッセージのすべてのプロパティの他に、ウィル・トピック、QoS レベル、保持フラグ、メッセージ・ペイロードを持ちます。

クライアントがQMqttClient::disconnectFromHost() を呼び出して通常の方法でブローカーから切断すると、ブローカーはウィル・メッセージを破棄します。必要であれば、クライアントは切断する前に必要なメッセージをすべて送信する責任があります。

保持メッセージ

保持メッセージはブローカー側に保存されます。将来クライアントが接続すると、そのようなメッセージを受け取ることになります。典型的な使用例は、パブリッシャーの現在の健康状態を保持メッセージに格納することです。サブスクライバーはそのステータスに関するメッセージを即座に受け取ります。

ブローカーは指定されたトピックに対して最後に送信されたretaintedメッセージのみを保存することができます。クライアントがQoSレベルゼロでretainされたメッセージを発行した場合、 ブローカーでそのトピックに対して以前にretainされたメッセージは破棄されなけれ ばならない。ブローカーは最後のメッセージを保存すべきですが、廃棄することもできます。これはブローカーの実装に依存します。