MQTT - AWS IoT Core

MQTT

MQTTは、制約のあるデバイス用に設計され、軽量で広く採用されているメッセージングプロトコルです。MQTT の AWS IoT のサポートは、MQTT v3.1.1 の仕様に基づいており、いくつかの違いがあります. AWS IoTが MQTT v3.1.1 仕様とどのように異なるかについては、「AWS IoT と MQTT バージョン 3.1.1 の仕様の違い」を参照してください。

AWS IoT Core は、MQTT プロトコルと MQTT over WSS プロトコルを使用し、クライアント ID で識別されるデバイス接続をサポートします。AWS IoTDevice SDKsは両方のプロトコルをサポートしており、デバイスを AWS IoTに接続するための推奨される方法です。AWS IoT Device SDK は、デバイスとクライアントが AWS IoT Core サービスに接続してアクセスするために必要な機能をサポートします。デバイス SDK は、AWS IoTサービスが必要とする認証プロトコルと、MQTT プロトコルと MQTT over WSS プロトコルが必要とする接続 ID 要件をサポートします。AWS Device SDK を使用して AWS IoT に接続する方法と、サポートされている言語での AWS IoTの例へのリンクについては、AWS IoT Device SDK を使用した MQTT との接続を参照してください。MQTT メッセージの認証メソッドとポートマッピングの詳細については、プロトコル、ポートマッピング、認証 を参照してください。

AWS IoT Device SDK を使用して AWS IoT に接続することをお勧めしますが、必須ではありません。ただし、AWS IoT Device SDK を使用しない場合は、必要な接続と通信のセキュリティを提供する必要があります。クライアントは、接続リクエストで Server Name Indication (SNI) TLS extension を送信する必要があります。SNI を含まない接続試行は拒否されます。詳細については、「AWS IoT のトランスポートセキュリティ」を参照してください。IAM ユーザーと AWS 認証情報を使用してクライアントを認証するクライアントは、正しい署名バージョン 4 認証を提供する必要があります。

AWS IoT Device SDK を使用した MQTT との接続

このセクションには、AWS IoT Device SDK へのリンクと、デバイスを AWS IoT に接続する方法を示すサンプルプログラムのソースコードへのリンクが含まれています。ここでリンクされているサンプルアプリケーションは、MQTT プロトコルと MQTT over WSS を使用して AWS IoT に接続する方法を示しています。

C++

デバイスへ接続するためのAWS IoT C++ Device SDK の使用

  • C++ での MQTT 接続例を示すサンプルアプリケーションのソースコード

  • GitHubのAWS IoT C++ Device SDK v2

Python

Python用AWS IoTDevice SDK を使用したデバイスの接続

JavaScript

JavaScript用 AWS IoTDevice SDKを使用したデバイスの接続

  • JavaScriptでの MQTT 接続例を示すサンプルアプリケーションのソースコード

  • GitHubのfor JavaScript v2用AWS IoT Device SDK

Java

Java用AWS IoTDevice SDKを使用したデバイスの接続

Embedded C

Embedded C用AWS IoTDevice SDKを使用したデバイスの接続

重要

この SDK は、経験豊富な組み込みソフトウェアデベロッパーによる使用を想定しています。

  • Embedded C での MQTT 接続例を示すサンプルアプリケーションのソースコード

  • GitHubのEmbedded C用AWS IoT Device SDK

MQTTサービス (QoS) 品質オプション

AWS IoT と AWS IoT Device SDK は、MQTT サービス品質 (QoS) レベル 01 をサポートしています。MQTT プロトコルは QoS の 3 番目のレベルであるレベル 2 を定義しますが、AWS IoT はそれをサポートしていません。MQTT プロトコルのみが QoS 機能をサポートします。HTTPS では QoS はサポートされません。

この表は、各 QoS レベルが、メッセージブローカーに発行されたメッセージ、およびメッセージブローカーによって発行されたメッセージにどのように影響するかを示しています。

次の QoS レベルを使用...

メッセージは...

コメント

QoS レベル 0

送信回数 0 回以上

このレベルは、信頼できる通信リンクを介して送信されるメッセージや、見逃しても問題がないメッセージに使用する必要があります。

QoS レベル 1

少なくとも 1 回送信され、PUBACK 応答が受信されるまで繰り返し送信されます

送信者が正常に配信されたことを示す PUBACK 応答を受信するまで、メッセージは完了したとはみなされません。

MQTT 永続的セッションの使用

永続セッションは、クライアントによって承認されていない、サービスの品質 (QoS) が 1 のクライアントのサブスクリプションとメッセージを保存します。コネクテッドデバイスが永続セッションに再接続すると、セッションが再開され、そのサブスクリプションが復元され、再接続前に受信され、クライアントによって確認されていないサブスクライブされたメッセージがクライアントに送信されます。

永続セッションの作成

MQTT 永続的セッションを作成するには、CONNECT メッセージを送信して、cleanSession フラグを 0 に設定します。CONNECT メッセージを送信したクライアントのセッションが存在しない場合は、新しい永続セッションが作成されます。クライアントのセッションが既に存在する場合は、クライアントは既存のセッションを再開します。

永続セッション中の操作

クライアントは、connection acknowledged (CONNACK) メッセージの sessionPresent 属性を調べて、永続的セッションが存在するかどうかを確認します。sessionPresent1 の場合、永続セッションが存在し、クライアントの保存済みメッセージは、クライアントが CONNACK を受信した直後にクライアントに配信されます。これについては、永続セッションへの再接続後のメッセージトラフィックを参照してください。sessionPresent1 の場合、クライアントは再サブスクライブする必要はありません。ただし、sessionPresent0 である場合は、永続的セッションが存在しないため、クライアントはそのトピックフィルターに再度サブスクライブする必要があります。

クライアントは永続セッションに参加した後も、各オペレーションにフラグを追加することなく、メッセージの発行とトピックフィルターのサブスクライブを行うことができます。

永続セッションへの再接続後のメッセージトラフィック

永続的セッションは、クライアントと MQTT メッセージブローカーの間の継続的な接続を表します。クライアントが永続的セッションを使用してメッセージブローカーに接続すると、クライアントが接続中に作成するすべてのサブスクリプションがメッセージブローカーによって保存されます。クライアントの接続が切断されると、クライアントがサブスクライブしているトピックにパブリッシュされた未確認の QoS 1 メッセージと新しい QoS 1 メッセージが保存されます。メッセージはアカウントの制限に従って保存され、その制限を超えるメッセージは削除されます。永続的なメッセージの制限の詳細については、「 AWS IoT Core のエンドポイントとクォータ」を参照してください。クライアントが永続的セッションに再接続すると、すべてのサブスクリプションが回復され、保存されているすべてのメッセージがクライアントに送信されます。その際の最大レートは 1 秒あたり 10 メッセージです。

再接続後、保存されたメッセージは、Publish requests per second per connection 制限に達するまで、現在のメッセージトラフィックとともに、1 秒あたり 10 個の保存されたメッセージに制限されたレートでクライアントに送信されます。保存されたメッセージの配信レートは制限されているため、再接続後にセッションに 10 個を超える保存されたメッセージがある場合、すべての保存されたメッセージを配信するには数秒かかります。

永続セッションの終了

次の条件は、永続的セッションの終了方法を記述します。

  • 永続セッションの有効期限が経過したとき。永続セッションの有効期限タイマーは、クライアントの切断または接続のタイムアウトによってクライアントが切断されたことをメッセージブローカーが検出すると開始されます。

  • クライアントが cleanSession フラグを 1 に設定する CONNECT メッセージを送信したとき。

注記

セッションの終了時にクライアントに送信されるのを待機している保存済みメッセージは破棄されます。ただし、送信できなかった場合でも、標準のメッセージングレートで請求されます。メッセージの料金の詳細については、「 AWS IoT Core の料金」を参照してください。有効期限の時間間隔を設定できます。

永続セッションの有効期限が切れた後の再接続

有効期限が切れる前にクライアントが永続セッションに再接続しない場合、セッションは終了し、保存されたメッセージは破棄されます。セッションの有効期限が切れた後に cleanSession フラグを使用してクライアントが 0 に再接続すると、サービスは新しい永続的セッションを作成します。前のセッションのサブスクリプションまたはメッセージは、前のセッションの有効期限が切れたときに破棄されたため、このセッションでは使用できません。

永続セッションのメッセージ料金

メッセージブローカーがクライアントまたはオフラインの永続セッションにメッセージを送信すると、メッセージの課金が発生し、 AWS アカウント に請求されます。永続セッションを持つオフラインデバイスが再接続してセッションを再開すると、保存されたメッセージがデバイスに配信され、アカウントに再び課金されます。メッセージの料金の詳細については、「 AWS IoT Core の料金 - メッセージング」を参照してください。

標準の制限引き上げプロセスを使用すると、デフォルトの永続セッションの有効期間を 1 時間引き上げることができます。セッションの有効期限を延長すると、メッセージ料金が増加する可能性があることに注意してください。これは、時間を延長するとオフラインデバイスに保存されるメッセージが増える可能性があり、標準のメッセージング料金でこれらの追加のメッセージが課金され、アカウントに請求されるためです。セッションの有効期限は概算であり、セッションはアカウントの制限よりも最長で 30 分長く持続する可能性があります。ただし、セッションはアカウントの制限より短くなることはありません。セッションの制限の詳細については、「AWS Service Quotas」を参照してください。

MQTT 保持メッセージを使用する

AWS IoT Core は、MQTT v3.1.1で説明されているRETAIN フラグをサポートしています。クライアントが公開する MQTT メッセージに RETAIN フラグを設定すると、 AWS IoT Core はメッセージを保存します。その後、それは新しいサブスクライバーに送信され、GetRetainedMessage操作を呼び出して取得され、AWS IoTconsoleに表示される事が可能になります。 AWS IoT Core は、最後に更新またはアクセスされてから 3 年間保持されたメッセージを保管します。3 年後、メッセージは削除されます。

MQTT 保持メッセージの使用例

  • 初期設定メッセージとして

    保持されたMQTTメッセージは、クライアントがトピックにサブスクライブした後、クライアントに送信されます。トピックをサブスクライブするすべてのクライアントが、サブスクライブ後すぐに 保持されたMQTTメッセージを受信できるようにする場合は、設定されたRETAIN フラッグで設定されたメッセージを発行する事ができます。サブスクライブしているクライアントはまた、新しい設定メッセージが発行されるたびに、その設定に対する更新が受信できます。

  • 最新のメッセージとして

    デバイスは、 AWS IoT Core が現在の状態メッセージを保存するように、それらにRETAIN フラッグを設定する事ができます。アプリケーションは、接続または再接続するときに、このトピックをサブスクライブし、保持されているメッセージのトピックをサブスクライブした直後に、最後に報告された状態を取得できます。このようにして、現在の状態を確認するために、デバイスからの次のメッセージまで待つ必要がなくなります。

AWS IoT Core において保持されたMQTTメッセージを使用した一般的なタスク

AWS IoT Core は、MQTT メッセージを RETAIN フラグで保存します。これらの保持されたメッセージは、通常の MQTT メッセージとしてトピックにサブスクライブしたすべてのクライアントに送信されると同時に、トピックへの新しいサブスクライバーに送信するために保存されます。

保持されたMQTTメッセージは、クライアントがメッセージにアクセスすることを許可するために特定のポリシーアクションが必要です。保持されるメッセージポリシーの使用例については、保持されたメッセージポリシーの例を参照してください。

このセクションでは、保持されるメッセージに関連する一般的な操作について説明します。

  • 保持メッセージの作成

    クライアントは、MQTT メッセージを発行するときにメッセージを保持するかどうかを決定します。クライアントはメッセージを発行する時、Device SDKを使用する事で、RETAIN フラッグを設定できます。アプリケーションおよびサービスは、Publishactionを使用してMQTTメッセージを発行する時に、RETAIN フラッグを設定する事ができます。

    トピック名ごとに 1 つのメッセージのみが保持されます。トピックに対して発行されたRETAIN フラッグが付いた新しいメッセージは、以前にトピックに送信されたあらゆる既存の保持メッセージを置き換えます。

    注意: RETAIN フラッグが設定された状態で予約済みのトピックに対して発行する事はできません。

  • 保持されたメッセージのトピックのサブスクライブ

    クライアントは、他の MQTT メッセージトピックと同様に、保持されるメッセージトピックをサブスクライブします。保持メッセージのトピックをサブスクライブすることによって受信される保持メッセージには、RETAIN フラグが設定されています。

    保持されたメッセージは、クライアントが、0 バイトのメッセージペイロードを持つ保持メッセージを保持メッセージトピックに発行する時、 AWS IoT Core から削除されます。保持されているメッセージのトピックをサブスクライブしたクライアントも、0 バイトのメッセージを受信する事になります。

    保持されたメッセージトピックを含むワイルドカードトピックフィルターをサブスクライブすると、クライアントは、保持されたメッセージのトピックに発行された後続のメッセージを受信できますが、サブスクリプション時に保持されたメッセージは配信されません。

    注意:サブスクリプション時に保持されたメッセージを受信するには、サブスクリプション要求のトピックフィルターが、保持されたメッセージのトピックと完全に一致する必要があります。

    保持メッセージ・トピックをサブスクライブしたときに受信される保持メッセージには、RETAIN フラグが設定されます。サブスクライブしているクライアントが、サブスクライブ後に受信するメッセージに、このフラッグは設定されません。

  • 保持されたメッセージの取得

    保持されたメッセージは、保持されたメッセージでトピックをサブスクライブすると、クライアントに自動的に配信されます。クライアントがサブスクリプション時に保持メッセージを受信するには、保持メッセージの正確なトピック名をサブスクライブする必要があります。保持されたメッセージトピックを含むワイルドカードトピックフィルターをサブスクライブすると、クライアントは、保持されたメッセージのトピックに発行された後続のメッセージを受信できますが、サブスクリプション時に保持されたメッセージは配信されません。

    サービスとアプリは、ListRetainedMessagesおよびGetRetainedMessageを呼び出す事によって、保持されているメッセージを一覧表示および取得する事ができます。

    クライアントは、RETAIN フラグを設定しなくても、保持されているメッセージのトピックにメッセージを発行できます。これは、保持されたメッセージが、トピックをサブスクライブすることで受信したメッセージと一致しないなど、予期しない結果を発生させる可能性があります。

  • 保持されたメッセージのトピックの一覧表示

    保持されたメッセージは、ListRetainedMessagesを呼び出す事で、リスト化する事ができ、保持されたメッセージはAWS IoTconsoleに表示する事ができます。

  • 保持されたメッセージの詳細の取得

    GetRetainedMessageを呼び出す事で、保持されたメッセージの詳細を取得する事ができ、それらは、AWS IoTconsoleに表示する事ができます。

  • Will メッセージの保持

    デバイス接続時に作成されるMQTTウィルメッセージConnect Flag bitsフィールドにWill Retainフラッグを設定する事で保持する事ができます。

  • 保持されたメッセージを削除する

    デバイス、アプリケーション、およびサービスは、RETAIN フラグが設定されたメッセージと、削除するメッセージのトピック名に空の (0 バイト) メッセージペイロードを発行することで、保持されたメッセージを削除する事ができます。このようなメッセージは、保持されたメッセージを AWS IoT Core から削除し、トピックへのサブスクリプションを持つクライアントに送信されますが、 AWS IoT Core によっては保持されません。

    保持されたメッセージは、AWS IoT コンソールで保持されたメッセージにアクセスすることによって、インタラクティブに削除することもできます。AWS IoT コンソールを使用して削除される保持されたメッセージも、保持されたメッセージのトピックにサブスクライブしているクライアントに対して 0 バイトメッセージを送信します。

    保持されているメッセージは、削除後に復元できません。クライアントは、削除されたメッセージの代わりに保持された新しいメッセージを発行する必要があります。

  • 保持されるメッセージのデバッグとトラブルシューティング

    AWS IoTconsoleは、保持されたメッセージのトラブルシューティングに役立つツールをいくつか提供します。

    • 保持されたメッセージのページ

      AWS IoTコンソールの保持されたメッセージのページは、現在の地域で、アカウントによって保存された保持されたメッセージのページ分けされたリストを提供します。このページからできること:

      • メッセージペイロード、QoS、受信時間など、保持されたメッセージそれぞれの詳細を確認してください。

      • 保持されたメッセージの内容を更新します。

      • 保持されているメッセージを削除します。

    • MQTT テストクライアント

      AWS IoTコンソールのMQTT テストクライアントページは、MQTT トピックにサブスクライブおよび発行する事ができます。公開オプションは、どのようにデバイスが動作するかをシミュレートするために発行するメッセージにRETAIN フラグを設定してくれます。

    予期せぬ結果の一部は、保持されたメッセージの AWS IoT Core での実行方法の側面が原因である可能性があります。

    • 保持されるメッセージの制限

      アカウントが保持されるメッセージの最大数を保存している場合、 AWS IoT Core は、保持されたメッセージの一部が削除され、保持されたメッセージ数が制限を下回るまで、RETAIN が設定され、ペイロードが 0 バイトを超える状態で発行されたメッセージに対してスロットルされたレスポンスを返します。

    • 保持されたメッセージ配信順序

      保持されたメッセージおよびサブスクライブされたメッセージ配信のシーケンスは保証されません。

請求と保持メッセージ

AWS IoTコンソールを使用あるいはPublishを呼び出す事で、クライアントからのRETAIN フラグが設定されたメッセージを発行する事は、 AWS IoT Core 料金表-メッセージングで説明されている追加メッセージング料金が発生します。

AWS IoTコンソールの使用またはGetRetainedMessageを呼び出してクライアントによって保持されたメッセージを取得する場合、通常の API 使用料金に加えて、メッセージング料金が発生します。追加料金については、 AWS IoT Core 料金表-メッセージングに説明されています。

予期せずデバイス接続が切断された際、発行されるMQTTウィルメッセージは、 AWS IoT Core 料金表-メッセージングで説明されているメッセージング料金が発生します。

メッセージの料金の詳細については、「 AWS IoT Core の料金 - メッセージング」を参照してください。

保持されたMQTTメッセージと永続MQTTセッションの比較

保持メッセージと永続セッションは、MQTT 3.1.1 の標準機能であり、オフライン中に発行されたメッセージをデバイスが受信できるようにします。保持されたメッセージは、永続的なセッションから発行する事ができます。このセクションでは、これらの機能の主な側面と、それらがどのように連携するかについて説明します。

メッセージの保持

永続セッション

永続セッションで保持されたメッセージ

主な特徴:

保持されたメッセージは、接続後に、デバイスを設定または大規模なグループにデバイスを通知をするために使用する事ができます。

保持メッセージは、再接続後にトピックに発行された最後のメッセージのみをデバイスに受信させる場合にも使用できます。

永続セッションは、接続が断続的で、いくつかの重要なメッセージを受信しない可能性があるデバイスに役立ちます。

デバイスは、永続的なセッションに接続して、オフライン中に送信されたメッセージを受信できます。

保持メッセージは、通常セッションと永続セッションの両方で使用できます。

保持メッセージを使用すると、デバイスがオンラインになったときに、デバイスの環境に関する設定情報が提供できます。初期設定には、サブスクライブする他のメッセージのトピックのリストや、ローカルタイムゾーン設定方法についての情報を含める事ができます。

接続が断続的なセルラーネットワーク経由で接続するデバイスは、デバイスがネットワーク圏外またはセルラー無線をオフにする必要があるときに送信される重要なメッセージを受信し損ねる事がないように、永続セッションを使う事ができます。

永続セッションサンプルのセルラーデバイスは、初期接続時の初期設定を受信するために、保持メッセージを使用する事ができます。

トピックへの初回購読時に受信したメッセージ

保持されたメッセージを持つトピックをサブスクライブすると、最新の保持されたメッセージが受信されます。

保持されたメッセージがないトピックをサブスクライブすると、そのトピックに発行されるまでメッセージを受信しません。

保持されたメッセージを持つトピックをサブスクライブすると、最新の保持されたメッセージを受信します。

再接続後にサブスクライブされたトピック

永続セッションを使用しない場合、クライアントは再接続後にトピックをサブスクライブする必要があります。

サブスクライブされたトピックは、再接続後に復元されます。

サブスクライブされたトピックは、再接続後に復元されます。

再接続後に受信したメッセージ

保持されたメッセージを持つトピックをサブスクライブすると、最新の保持されたメッセージが受信されます。

デバイスが切断されている間に QOS = 1 で発行され、QOS = 1 でサブスクライブされたすべてのメッセージは、デバイスの再接続後に送信されます。

デバイスが切断されている間に発送された、QOS = 1 で発行され、QOS = 1 でサブスクライブされたすべてのメッセージは、デバイスの再接続後に送信されます。

クライアントがサブスクライブしたトピックからの更新済みの保持されたメッセージも、クライアントに送信されます。

クライアントがオフラインのときに複数の保持されたメッセージが 1 つのトピックに発行された場合、再接続後、そのトピックに対して複数の保存済みの保持されたメッセージが受信できます。

データ/セッションの有効期限

保持されたメッセージは期限切れになりません。これらは、置き換えられる、または削除されるまで保存されます。

永続セッションは、クライアントがタイムアウト期間内に再接続しない場合、期限切れになります。永続セッションの有効期限が切れると、QOS = 1 で発行され、デバイスが切断されている間に QOS = 1 でサブスクライブされたクライアントのサブスクリプションと保存済みメッセージが削除されます。

永続的なセッションでのセッションの有効期限の詳細については、「MQTT 永続的セッションの使用」を参照してください。。

保持されたメッセージは期限切れになりません。有効期限が切れた永続セッション内から送信された場合でも、置き換えられるか、削除されるまで保存されます。永続セッションの有効期限が切れると、QOS = 1 で発行され、デバイスが切断されている間に QOS = 1 でサブスクライブされたクライアントのサブスクリプションと保存済みメッセージが削除されます。

永続的ストレージについては、MQTT 永続的セッションの使用 を参照してください。

Retreated Messages を使用すると、発行するクライアントは、接続後にメッセージを保持してデバイスに配信するかどうか、デバイスに以前のセッションがあったかどうかを判断します。メッセージを保存する選択は発行者が行い、保存されたメッセージは、QoS 0 または QoS 1 のサブスクリプションでサブスクライブする現在および将来のすべてのクライアントに配信されます。保持メッセージは、特定のトピックに一度に 1 つのメッセージのみを保持します。

アカウントが保持されるメッセージを最大数保存している場合、 AWS IoT Core は、保持されたメッセージの一部が削除され、保持されたメッセージの数が上限を下回るまで、RETAIN が設定され、ペイロードが 0 バイトを超える状態で発行されたメッセージに対してスロットルされたレスポンスを返します。

MQTT 保持メッセージとAWS IoTデバイスシャドウ

保持メッセージとデバイスシャドウはどちらもデバイスからのデータを保持しますが、動作が異なり、目的も異なります。このセクションでは、それらの類似点と相違点について説明します。

メッセージの保持

デバイスシャドウ

メッセージペイロードに事前定義された構造またはスキーマがある

実装によって定義されている通り。MQTT は、メッセージペイロードの構造やスキーマを指定しません。

AWS IoTは特定のデータ構造をサポートします。

メッセージ・ペイロードを更新すると、イベント・メッセージが生成されます

保持されたメッセージを発行すると、サブスクライブされたクライアントにメッセージが送信されますが、追加の更新メッセージは生成されません。

Device Shadow を更新すると、変更を説明するメッセージを更新します

メッセージの更新には番号が付けられます

保持されているメッセージには、自動的には番号が付けられません。 Device Shadow ドキュメントには、自動バージョン番号とタイムスタンプがあります。

メッセージペイロードは、モノのリソースにアタッチされます

保持されたメッセージは モノの リソースに添付されません。

デバイスシャドウは モノの リソースにアタッチされます。

メッセージペイロードの個々の要素の更新

メッセージの個々の要素は、メッセージペイロード全体を更新しなければ変更できません。

Device Shadow ドキュメントの個々の要素は、Device Shadow ドキュメント全体を更新しなくても、更新できます。

クライアントは、サブスクリプションすると直ちにメッセージデータを受信します

クライアントは、保持メッセージを持つトピックをサブスクライブした後、保持メッセージを自動的に受信します。

クライアントはDevice Shadowの更新をサブスクライブできますが、現在の状態を意図的に要求する必要があります。

インデックス作成と検索性

保持されたメッセージは検索用にインデックス付けされません。

フリートインデックス作成は、検索および集計のためにDevice Shadowデータをインデックス化します

connectAttributes の使用

ConnectAttributes は、PersistentConnectLastWill などの IAM ポリシーの接続メッセージで使用する属性を指定できます。ConnectAttributes を使用すると、デフォルトではデバイスに新機能へのアクセスを許可しないポリシーを構築できます。これは、デバイスが侵害された場合に役立ちます。

connectAttributes でサポートされる機能は以下のとおりです。

PersistentConnect

PersistentConnect 機能を使用して、クライアントとブローカー間の接続が中断されたときに、接続中にクライアントが作成したすべてのサブスクリプションを保存します。

LastWill

LastWill 機能を使用して、クライアントが予期せず切断したときにメッセージを LastWillTopic に発行します。

デフォルトでは、ポリシーには非永続的な接続があり、この接続用に渡される属性はありません。永続的な接続が必要な場合は、IAM ポリシーで永続的な接続を指定する必要があります。

ConnectAttributes 例については、接続ポリシーの例を参照してください。

AWS IoT と MQTT バージョン 3.1.1 の仕様の違い

メッセージブローカーの実装は MQTT v3.1.1 の仕様に基づいていますが、次の点で仕様とは異なります。

  • AWS IoT は MQTT サービス品質 (QoS) レベル 0 と 1 のみをサポートします。AWS IoT は、QoS レベル 2 でのパブリッシュまたはサブスクライブをサポートしていません。QoS 2 レベル 2 がリクエストされると、メッセージブローカーは PUBACK または SUBACK を送信しません。

  • AWS IoT では、QoS レベル 0 でトピックにサブスクライブすると、メッセージが 0 回以上配信されます。メッセージは複数回配信される場合があります。複数回配信されるメッセージは、異なるパケット ID を使用して送信される場合があります。これらの場合、DUP フラグは設定されません。

  • 接続リクエストに応答するとき、メッセージブローカーは CONNACK メッセージを送信します。このメッセージには、接続で前のセッションを再開するかどうかを示すフラグが含まれます。

  • 追加の制御パケットまたは切断リクエストを送信する前に、クライアントは、AWS IoT メッセージブローカーから CONNACK メッセージがデバイスで受信されるのを待機する必要があります。

  • クライアントがトピックをサブスクライブすると、メッセージブローカーは SUBACK を送信してから、クライアントが新しい一致するメッセージの受信を開始するまでに、遅延が生じる場合があります。

  • クライアントが、トピックをサブスクライブするために、#トピックフィルターでワイルドカード文字を使用する場合、トピック階層において、そのレベルとそれ以下の文字列はすべて一致します。ただし、親トピックが一致しません。例えば、トピックへのサブスクリプションsensor/#は、トピックsensor/sensor/temperaturesensor/temperature/room1に発行されたメッセージを受信しますが、sensorに発行されたメッセージは受信しません。 ワイルドカードの使用の詳細については、「トピックフィルター」を参照してください。

  • メッセージブローカーは、クライアント ID を使用して、各クライアントを識別します。クライアント ID は MQTT ペイロードの一部としてクライアントからメッセージブローカーに渡されます。クライアント ID が同じ 2 つのクライアントがメッセージブローカーに同時に接続することはできません。あるクライアントが別のクライアントのクライアント ID を使用してメッセージブローカーに接続すると、新しいクライアント接続が受け入れられ、以前に接続されたクライアントは切断されます。

  • まれに、メッセージブローカーは、パケット ID が異なる同じ論理 PUBLISH メッセージを再送信する場合があります。

  • ワイルドカード文字を含むトピックフィルターへのサブスクリプションは、保持されたメッセージを受信できません。保持されたメッセージを受信するには、サブスクライブ要求に、保持されたメッセージ・トピックと完全に一致するトピック・フィルタが含まれている必要があります。

  • メッセージブローカーはメッセージと ACK の正しい受信順序を確保するわけではありません。