MQTT
MQTT
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
AWS IoT Device SDK を使用した MQTT との接続
このセクションには、AWS IoT Device SDK へのリンクと、デバイスを AWS IoT に接続する方法を示すサンプルプログラムのソースコードへのリンクが含まれています。ここでリンクされているサンプルアプリケーションは、MQTT プロトコルと MQTT over WSS を使用して AWS IoT に接続する方法を示しています。
MQTTサービス (QoS) 品質オプション
AWS IoT と AWS IoT Device SDK は、MQTT サービス品質 (QoS) レベル 0と12 を定義しますが、AWS IoT はそれをサポートしていません。MQTT プロトコルのみが QoS 機能をサポートします。HTTPS は、クエリ文字列パラメータ ?qos=qos を渡すことによって QoS をサポートし、ここで、値は 0 または 1 にすることができます。
この表は、各 QoS レベルが、メッセージブローカーに発行されたメッセージ、およびメッセージブローカーによって発行されたメッセージにどのように影響するかを示しています。
|
次の QoS レベルを使用... |
メッセージは... |
コメント |
|---|---|---|
|
QoS レベル 0 |
送信回数 0 回以上 |
このレベルは、信頼できる通信リンクを介して送信されるメッセージや、見逃しても問題がないメッセージに使用する必要があります。 |
|
QoS レベル 1 |
少なくとも 1 回送信され、 |
送信者が正常に配信されたことを示す |
MQTT 永続的セッションの使用
永続セッションは、クライアントによって承認されていない、サービスの品質 (QoS) が 1 のクライアントのサブスクリプションとメッセージを保存します。コネクテッドデバイスが永続セッションに再接続すると、セッションが再開され、そのサブスクリプションが復元され、再接続前に受信され、クライアントによって確認されていないサブスクライブされたメッセージがクライアントに送信されます。
永続セッションの作成
MQTT 永続的セッションを作成するには、CONNECT メッセージを送信して、cleanSession フラグを 0 に設定します。CONNECT メッセージを送信したクライアントのセッションが存在しない場合は、新しい永続セッションが作成されます。クライアントのセッションが既に存在する場合は、クライアントは既存のセッションを再開します。
永続セッション中の操作
クライアントは、connection acknowledged (CONNACK) メッセージの sessionPresent 属性を調べて、永続的セッションが存在するかどうかを確認します。sessionPresent が 1 の場合、永続セッションが存在し、クライアントの保存済みメッセージは、クライアントが CONNACK を受信した直後にクライアントに配信されます。これについては、「永続セッションへの再接続後のメッセージトラフィック」を参照してください。sessionPresent が 1 の場合、クライアントは再サブスクライブする必要はありません。ただし、sessionPresent が 0 である場合は、永続的セッションが存在しないため、クライアントはそのトピックフィルターに再度サブスクライブする必要があります。
クライアントは永続セッションに参加した後も、各オペレーションにフラグを追加することなく、メッセージの発行とトピックフィルターのサブスクライブを行うことができます。
永続セッションへの再接続後のメッセージトラフィック
永続的セッションは、クライアントと 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.1GetRetainedMessage オペレーションを呼び出して取得され、AWS IoT
保持された MQTT メッセージの使用例
-
初期設定メッセージとしての使用
保持されたMQTTメッセージは、クライアントがトピックにサブスクライブした後、クライアントに送信されます。トピックをサブスクライブするすべてのクライアントが、サブスクライブ後すぐに 保持されたMQTTメッセージを受信できるようにする場合は、設定されたRETAIN フラッグで設定されたメッセージを発行する事ができます。サブスクライブしているクライアントはまた、新しい設定メッセージが発行されるたびに、その設定に対する更新が受信できます。
-
最新のメッセージとして
デバイスは、AWS IoT Coreが現在の状態メッセージを保存するように、それらにRETAIN フラッグを設定する事ができます。アプリケーションは、接続または再接続するときに、このトピックをサブスクライブし、保持されているメッセージのトピックをサブスクライブした直後に、最後に報告された状態を取得できます。こうすることで、現在の状態を確認するために、デバイスからの次のメッセージを待つ必要がなくなります。
このセクションの内容:
AWS IoT Coreにおいて保持されたMQTTメッセージを使用した一般的なタスク
AWS IoT Core が、RETAIN フラグが設定された MQTT メッセージを保存します。これらの保持されたメッセージは、通常の 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、受信時間など、保持されたメッセージそれぞれの詳細を確認してください。
-
保持されたメッセージの内容を更新する。
-
保持されたメッセージを削除する。
-
-
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 の料金 – メッセージング
保持された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データをインデックス化します |
connectAttributes の使用
ConnectAttributes を使用すると、PersistentConnect や LastWill などの 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 メッセージがデバイスで受信されるのを待機する必要があります。
-
クライアントが接続を許可されていないために接続が拒否された場合は、AWS IoT は CONNACK エラーコード 5 ではなくエラーコード 7 を返します。
-
クライアントがトピックをサブスクライブすると、メッセージブローカーは SUBACK を送信してから、クライアントが新しい一致するメッセージの受信を開始するまでに、遅延が生じる場合があります。
-
クライアントが、トピックをサブスクライブするために、
#トピックフィルターでワイルドカード文字を使用する場合、トピック階層において、そのレベルとそれ以下の文字列はすべて一致します。ただし、親トピックは照合されません。例えば、トピックへのサブスクリプションsensor/#は、トピックsensor/sensor/temperaturesensor/temperature/room1に発行されたメッセージを受信しますが、sensorに発行されたメッセージは受信しません。 ワイルドカードの使用の詳細については、「トピックフィルター」を参照してください。 -
メッセージブローカーは、クライアント ID を使用して、各クライアントを識別します。クライアント ID は MQTT ペイロードの一部としてクライアントからメッセージブローカーに渡されます。クライアント ID が同じ 2 つのクライアントがメッセージブローカーに同時に接続することはできません。あるクライアントが別のクライアントのクライアント ID を使用してメッセージブローカーに接続すると、新しいクライアント接続が受け入れられ、以前に接続されたクライアントは切断されます。
-
まれに、メッセージブローカーは、パケット ID が異なる同じ論理 PUBLISH メッセージを再送信する場合があります。
-
ワイルドカード文字を含むトピックフィルターへのサブスクリプションでは、保持されたメッセージの受信ができません。保持されたメッセージを受信するには、サブスクライブリクエストに、保持されたメッセージのトピックと完全に一致するトピックフィルターが含まれている必要があります。
-
メッセージブローカーはメッセージと ACK の正しい受信順序を確保するわけではありません。
-
すべてのパブリッシュリクエストのペイロードは 128 KB を超えることができません。AWS IoT Core は、このサイズより大きい発行リクエストや接続リクエストを拒否します。詳細については、AWS IoT リファレンスガイドの「AWS IoT Core メッセージブローカーとプロトコルの制限とクォータ」を参照してください。
