翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。
MQTT
MQTT
AWS IoT Core は、MQTT プロトコルと MQTT over WSS プロトコルを使用し、クライアント ID で識別されるデバイス接続をサポートします。AWS IoT デバイス SDKsは両方のプロトコルをサポートしており、デバイスを AWS IoT Coreに接続するための推奨される方法です。 AWS IoT Device SDKs、デバイスとクライアントが サービスに接続してアクセス AWS IoT するために必要な機能をサポートします。Device SDKs、 AWS IoT サービスが必要とする認証プロトコルと、MQTT プロトコルと MQTT over WSS プロトコルが必要とする接続 ID 要件をサポートします。 AWS Device SDK AWS IoT を使用して に接続する方法と、サポートされている言語 AWS IoT の の例へのリンクについては、「」を参照してくださいAWS IoT Device SDKs を使用した MQTT との接続。 SDKs MQTT メッセージの認証メソッドとポートマッピングの詳細については、プロトコル、ポートマッピング、認証 を参照してください。
AWS IoT Device SDKs を使用して に接続することをお勧めしますが AWS IoT、必須ではありません。ただし、 AWS IoT Device SDKsを使用しない場合は、必要な接続と通信のセキュリティを提供する必要があります。クライアントは、接続リクエストで Server Name Indication (SNI) TLS extension
このトピックの内容
AWS IoT Device SDKs を使用した MQTT との接続
このセクションでは、 AWS IoT Device SDKsへのリンクと、デバイスを に接続する方法を説明するサンプルプログラムのソースコードへのリンクを示します AWS IoT。ここでリンクされているサンプルアプリケーションは、MQTT プロトコルと MQTT over WSS AWS IoT を使用して に接続する方法を示しています。
注記
AWS IoT Device SDKs MQTT 5 クライアントをリリースしました。
MQTTサービス (QoS) 品質オプション
AWS IoT および AWS IoT Device SDKs、MQTT Quality of Service (QoS ) レベル 0
および 1
2
、サポート AWS IoT していません。MQTT プロトコルのみが QoS 機能をサポートします。HTTPS は、クエリ文字列パラメータ ?qos=qos
を渡すことによって QoS をサポートし、ここで、値は 0 または 1 にすることができます。
この表は、各 QoS レベルが、メッセージブローカーに発行されたメッセージ、およびメッセージブローカーによって発行されたメッセージにどのように影響するかを示しています。
次の QoS レベルを使用..。 |
メッセージは..。 |
コメント |
---|---|---|
QoS レベル 0 |
送信回数 0 回以上 |
このレベルは、信頼できる通信リンクを介して送信されるメッセージや、見逃しても問題がないメッセージに使用する必要があります。 |
QoS レベル 1 |
少なくとも 1 回送信され、 |
送信者が正常に配信されたことを示す |
MQTT 永続的セッション
永続セッションは、クライアントによって承認されていない、Quality of Service (QoS) が 1 のクライアントのサブスクリプションとメッセージを保存します。コネクテッドデバイスが永続セッションに再接続すると、セッションが再開され、そのサブスクリプションが復元され、再接続前に受信され、クライアントによって確認されていないサブスクライブされたメッセージがクライアントに送信されます。
保存されたメッセージの処理は、 CloudWatch および CloudWatch ログに記録されます。 CloudWatch および CloudWatch ログに書き込まれるエントリの詳細については、メッセージブローカーのメトリクス「」および「」を参照してくださいキューに保存されたログエントリ。
永続セッションの作成
MQTT 3 で、永続セッションを作成するには、CONNECT
メッセージを送信して、cleanSession
フラグを 0
に設定します。CONNECT
メッセージを送信したクライアントのセッションが存在しない場合は、新しい永続セッションが作成されます。クライアントのセッションが既に存在する場合は、クライアントは既存のセッションを再開します。クリーンセッションを作成するには、CONNECT
メッセージを送信して cleanSession
フラグを 1
に設定します。クライアントが切断してもブローカーはセッション状態を保存しません。
MQTT 5 では、Clean Start
フラグと Session Expiry Interval
を設定することで永続セッションを処理します。クリーンスタートは、接続セッションの開始と前のセッションの終了を制御します。Clean
Start
= 1
を設定すると、新しいセッションが作成され、以前のセッションが存在する場合は終了します。Clean Start
= 0
を設定すると、接続セッションは以前のセッションが存在する場合はそれを再開します。セッションの有効期限間隔は、接続セッションの終了を制御します。セッション有効期限間隔は、セッションが切断後も持続する時間を秒単位 (4 バイト整数) で指定します。Session Expiry interval
= 0
に設定すると、セッションは切断時にすぐに終了します。セッションの有効期限が CONNECT メッセージで指定されていない場合、デフォルトは 0 です。
MQTT 5 クリーンスタートとセッションの有効期限 | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
プロパティ値 | 説明 | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Clean Start = 1 |
新しいセッションを作成し、以前のセッションが存在する場合は終了します。 | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Clean Start = 0 |
以前のセッションが存在する場合、セッションを再開します。 | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Session Expiry Interval > 0 |
セッションを保持する。 | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Session Expiry interval = 0 |
セッションを保持しない。 |
MQTT 5 では、Clean Start
= 1
と Session
Expiry Interval
= 0
を設定すると、これは MQTT 3 のクリーンセッションと同等になります。Clean Start
=0
と Session Expiry Interval
> 0
を設定すると、これは MQTT 3 の永続セッションと同等になります。
注記
複数の MQTT バージョン (MQTT 3 と MQTT 5) の永続セッションはサポートされていません。MQTT 3 永続セッションを MQTT 5 セッションとして再開することはできません。その逆も同様です。
永続セッション中の操作
クライアントは、connection acknowledged (CONNACK
) メッセージの sessionPresent
属性を調べて、永続的セッションが存在するかどうかを確認します。sessionPresent
が 1
の場合、永続セッションが存在し、クライアントの保存済みメッセージは、クライアントが CONNACK
を受信した後にクライアントに配信されます。これについては、「永続セッションへの再接続後のメッセージトラフィック」を参照してください。sessionPresent
が 1
の場合、クライアントは再サブスクライブする必要はありません。ただし、sessionPresent
が 0
である場合は、永続的セッションが存在しないため、クライアントはそのトピックフィルターに再度サブスクライブする必要があります。
クライアントは永続セッションに参加した後も、各オペレーションにフラグを追加することなく、メッセージの発行とトピックフィルターのサブスクライブを行うことができます。
永続セッションへの再接続後のメッセージトラフィック
永続的セッションは、クライアントと MQTT メッセージブローカーの間の継続的な接続を表します。クライアントが永続的セッションを使用してメッセージブローカーに接続すると、クライアントが接続中に作成するすべてのサブスクリプションがメッセージブローカーによって保存されます。クライアントの接続が切断されると、クライアントがサブスクライブしているトピックにパブリッシュされた未確認の QoS 1 メッセージと新しい QoS 1 メッセージが保存されます。メッセージはアカウントの制限に従って保存されます。制限を超えるメッセージは削除されます。永続的なメッセージの制限の詳細については、「AWS IoT Core のエンドポイントとクォータ」を参照してください。クライアントが永続的セッションに再接続すると、すべてのサブスクリプションが回復され、保存されているすべてのメッセージがクライアントに送信されます。その際の最大レートは 1 秒あたり 10 メッセージです。MQTT 5 では、クライアントがオフラインのときにメッセージ有効期限が設定されたアウトバウンド QoS1 が期限切れになった場合、接続が再開された後、クライアントは期限切れメッセージを受信しません。
再接続後、保存されたメッセージは、Publish
requests per second per connection
制限に達するまで、現在のメッセージトラフィックとともに、1 秒あたり 10 個の保存されたメッセージに制限されたレートでクライアントに送信されます。保存されたメッセージの配信レートは制限されているため、再接続後にセッションに 10 個を超える保存されたメッセージがある場合、すべての保存されたメッセージを配信するには数秒かかります。
永続セッションの終了
永続セッションは、次の方法で終了できます。
-
永続セッションの有効期限が経過した。永続セッションの有効期限タイマーは、クライアントの切断または接続のタイムアウトによってクライアントが切断されたことをメッセージブローカーが検出すると開始されます。
-
クライアントが
cleanSession
フラグを1
に設定するCONNECT
メッセージを送信した。
MQTT 3 では、永続セッションの有効期限のデフォルト値は 1 時間で、これはアカウント内のすべてのセッションに適用されます。
MQTT 5 では、CONNECT パケットと DISCONNECT パケットのセッション有効期限間隔をセッションごとに設定できます。
DISCONNECT パケットのセッション有効期限間隔について:
-
現在のセッションのセッション有効期限間隔が 0 の場合、DISCONNECT パケットのセッション有効期限間隔を 0 より大きい値に設定することはできません。
-
現在のセッションのセッション有効期限間隔が 0 より大きく、DISCONNECT パケットのセッション有効期限間隔を 0 に設定した場合、セッションは DISCONNECT で終了します。
-
そうしないと、DISCONNECT パケットのセッション有効期限間隔が現在のセッションのセッション有効期限間隔を更新します。
注記
セッションの終了時にクライアントに送信されるのを待機している保存済みメッセージは破棄されます。ただし、送信できなかった場合でも、標準のメッセージングレートで請求されます。メッセージの料金の詳細については、「AWS IoT Core
の料金
永続セッションの有効期限が切れた後の再接続
有効期限が切れる前にクライアントが永続セッションに再接続しない場合、セッションは終了し、保存されたメッセージは破棄されます。セッションの有効期限が切れた後に cleanSession
フラグを使用してクライアントが 0
に再接続すると、サービスは新しい永続的セッションを作成します。前のセッションのサブスクリプションまたはメッセージは、前のセッションの有効期限が切れたときに破棄されたため、このセッションでは使用できません。
永続セッションのメッセージ料金
メッセージブローカーがクライアントまたはオフラインの永続セッションにメッセージを送信 AWS アカウント すると、メッセージは に課金されます。永続セッションを持つオフラインデバイスが再接続してセッションを再開すると、保存されたメッセージがデバイスに配信され、アカウントに再び課金されます。メッセージの料金の詳細については、「AWS IoT Core の料金 - メッセージング
標準の制限引き上げプロセスを使用すると、デフォルトの永続セッションの有効期間を 1 時間引き上げることができます。セッションの有効期限を延長すると、メッセージ料金が増加する可能性があることに注意してください。これは、時間を延長するとオフラインデバイスに保存されるメッセージが増える可能性があり、標準のメッセージング料金でこれらの追加のメッセージが課金され、アカウントに請求されるためです。セッションの有効期限は概算であり、セッションはアカウントの制限よりも最長で 30 分長く持続する可能性があります。ただし、セッションはアカウントの制限より短くなることはありません。セッションの制限の詳細については、「AWS Service Quotas」を参照してください。
保持された MQTT メッセージ
AWS IoT Core は、MQTT プロトコルで説明されている RETAIN フラグをサポートします。クライアントが発行する MQTT メッセージに RETAIN フラグを設定すると、 はメッセージ AWS IoT Core を保存します。その後、新しいサブスクライバーに送信し、GetRetainedMessage
オペレーションを呼び出して取得し、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 フラッグを設定できます。アプリケーションおよびサービスは、
Publish
actionを使用してMQTTメッセージを発行する時に、RETAIN フラッグを設定する事ができます。メッセージは、トピック名ごとに 1 つのみ保持されます。トピックに対して発行されたRETAIN フラッグが付いた新しいメッセージは、以前にトピックに送信されたあらゆる既存の保持メッセージを置き換えます。
注意: RETAIN フラッグが設定された状態で予約済みのトピックに対して発行する事はできません。
-
保持されたメッセージのトピックのサブスクライブ
クライアントは、他の MQTT メッセージトピックと同様に、保持されるメッセージトピックをサブスクライブします。保持メッセージのトピックをサブスクライブすることによって受信される保持メッセージには、RETAIN フラグが設定されています。
保持されたメッセージは、クライアントが 0 バイトのメッセージペイロードを持つ保持されたメッセージを保持されたメッセージトピックに発行 AWS IoT Core すると、 から削除されます。保持されているメッセージのトピックをサブスクライブしたクライアントも、0 バイトのメッセージを受信する事になります。
保持されたメッセージのトピックが含まれるワイルドカードトピックフィルターにサブスクライブすると、クライアントは保持されたメッセージのトピックに発行された後続のメッセージを受信できるようになりますが、トピックはサブスクライブ時に保持されたメッセージを配信しません。
注: サブスクライブ時に保持されたメッセージを受信するには、サブスクリプションリクエストのトピックフィルターが、保持されたメッセージのトピックと完全に一致する必要があります。
保持されたメッセージのトピックへのサブスクライブ時に受信する保持されたメッセージには、RETAIN フラグが設定されています。サブスクライブしているクライアントが、サブスクライブ後に受信するメッセージに、このフラッグは設定されません。
-
保持されたメッセージの取得
保持されたメッセージが、保持されたメッセージが含まれたトピックにサブスクライブするときに、クライアントに自動配信されます。クライアントがサブスクライブ時に保持されたメッセージを受信するには、保持されたメッセージの正確なトピック名にサブスクライブする必要があります。保持されたメッセージのトピックが含まれるワイルドカードトピックフィルターにサブスクライブすると、クライアントは保持されたメッセージのトピックに発行された後続のメッセージを受信できるようになりますが、トピックはサブスクライブ時に保持されたメッセージを配信しません。
サービスとアプリは、
ListRetainedMessages
およびGetRetainedMessage
を呼び出す事によって、保持されているメッセージを一覧表示および取得する事ができます。クライアントは、RETAIN フラグを設定しなくても、保持されているメッセージのトピックにメッセージを発行できます。これは、保持されたメッセージが、トピックをサブスクライブすることで受信したメッセージと一致しないなど、予期しない結果を発生させる可能性があります。
MQTT 5 では、保持メッセージにメッセージ有効期限が設定されていて保持メッセージの有効期限が切れると、そのトピックをサブスクライブする新規サブスクライバーは、サブスクリプションが成功しても保持メッセージを受信しません。
-
保持されたメッセージのトピックの一覧表示
保持されたメッセージは、
ListRetainedMessages
を呼び出す事で、リスト化する事ができ、保持されたメッセージはAWS IoT consoleに表示する事ができます。 -
保持されたメッセージの詳細情報の取得
GetRetainedMessage
を呼び出す事で、保持されたメッセージの詳細を取得する事ができ、それらは、AWS IoT consoleに表示する事ができます。 -
Will メッセージの保持
デバイス接続時に作成されるMQTTウィルメッセージ
は Connect Flag bits
フィールドにWill Retain
フラッグを設定する事で保持する事ができます。 -
保持されたメッセージの削除
デバイス、アプリケーション、およびサービスは、RETAIN フラグが設定されたメッセージと、削除するメッセージのトピック名に空の (0 バイト) メッセージペイロードを発行することで、保持されたメッセージを削除する事ができます。このようなメッセージは、保持されたメッセージを から削除し AWS IoT Core、トピックへのサブスクリプションを持つクライアントに送信されますが、 によって保持されません AWS IoT Core。
保持されたメッセージは、AWS IoT コンソール
で保持されたメッセージにアクセスすることによって、インタラクティブに削除することもできます。AWS IoT コンソール を使用して削除される保持されたメッセージも、保持されたメッセージのトピックにサブスクライブしているクライアントに対して 0 バイトメッセージを送信します。 保持されたメッセージの削除後に、それらを復元することはできません。クライアントは、削除されたメッセージの代わりに新しい保持されたメッセージを発行する必要があります。
-
保持されたメッセージのデバッグとトラブルシューティング
AWS IoT console
は、保持されたメッセージのトラブルシューティングに役立つツールをいくつか提供します。 -
保持されたメッセージ
のページ AWS IoT コンソールの保持されたメッセージのページは、現在の地域で、アカウントによって保存された保持されたメッセージのページ分けされたリストを提供します。このページからは、以下を実行できます。
-
メッセージペイロード、QoS、受信時間など、保持されたメッセージそれぞれの詳細を確認してください。
-
保持されたメッセージの内容を更新する。
-
保持されたメッセージを削除する。
-
-
MQTT テストクライアント
AWS IoT コンソールのMQTT テストクライアントページは、MQTT トピックにサブスクライブおよび発行する事ができます。公開オプションは、どのようにデバイスが動作するかをシミュレートするために発行するメッセージにRETAIN フラグを設定してくれます。
一部の予期しない結果は、保持されたメッセージが に実装される方法に関するこれらの側面の結果である可能性があります AWS IoT Core。
-
保持されるメッセージの制限
アカウントが保持されたメッセージの最大数を保存すると、 は、保持されたメッセージの一部が削除され、保持されたメッセージ数が制限を下回るまで、RETAIN セットと 0 バイトを超えるペイロードで発行されたメッセージに対してスロットリングされたレスポンス AWS IoT Core を返します。
-
保持されたメッセージの配信順序
保持されたメッセージとサブスクライブされたメッセージの配信順序は保証されていません。
-
請求と保持メッセージ
AWS IoT
コンソールを使用あるいはPublish
を呼び出す事で、クライアントからのRETAIN フラグが設定されたメッセージを発行する事は、AWS IoT Core 料金表-メッセージング
クライアント、 AWS IoT コンソール、または を呼び出して保持されたメッセージを取得すると、通常の API GetRetainedMessage
使用料金に加えてメッセージング料金が発生します。追加料金については、AWS IoT Core
料金表-メッセージング
予期せずデバイス接続が切断された際、発行されるMQTTウィルメッセージ
メッセージコストの詳細については、AWS IoT Core の料金 – メッセージング
保持されたMQTTメッセージと永続MQTTセッションの比較
保持メッセージと永続セッションは、MQTT の標準機能であり、オフライン中に発行されたメッセージをデバイスが受信できるようにします。保持されたメッセージは、永続的なセッションから発行する事ができます。このセクションでは、これらの機能の主な側面と、これらがどのように連携するかについて説明します。
保持されたメッセージ |
永続セッション |
|
---|---|---|
主な特徴 |
保持されたメッセージは、接続後に、デバイスを設定または大規模なグループにデバイスを通知するために使用することができます。 保持されたメッセージは、デバイスが再接続した後で、トピックに発行された最後のメッセージのみを受信するようにしたい場合にも使用できます。 |
永続セッションは、接続が断続的で、いくつかの重要なメッセージを受信しない可能性があるデバイスに役立ちます。 デバイスは、永続セッションで接続して、オフライン中に送信されたメッセージを受信できます。 |
例 |
保持メッセージを使用すると、デバイスがオンラインになったときに、デバイスの環境に関する設定情報が提供できます。初期設定には、サブスクライブする他のメッセージのトピックのリストや、ローカルタイムゾーン設定方法についての情報を含める事ができます。 |
接続が断続的なセルラーネットワーク経由で接続するデバイスは、デバイスがネットワーク圏外またはセルラー無線をオフにする必要があるときに送信される重要なメッセージを受信し損ねる事がないように、永続セッションを使う事ができます。 |
トピックへの初回サブスクライブ時に受信したメッセージ |
保持されたメッセージを持つトピックをサブスクライブすると、最新の保持されたメッセージが受信されます。 |
保持されたメッセージがないトピックをサブスクライブすると、そのトピックに発行されるまでメッセージを受信しません。 |
再接続後にサブスクライブされたトピック |
永続セッションを使用しない場合、クライアントは再接続後にトピックをサブスクライブする必要があります。 |
サブスクライブされたトピックは、再接続後に復元されます。 |
再接続後に受信したメッセージ |
保持されたメッセージを持つトピックをサブスクライブすると、最新の保持されたメッセージが受信されます。 |
デバイスが切断されている間に QOS = 1 で発行され、QOS = 1 でサブスクライブされたすべてのメッセージは、デバイスの再接続後に送信されます。 |
データ/セッションの有効期限 |
MQTT 3 では、保持されたメッセージに有効期限はありません。これらは、置き換えられる、または削除されるまで保存されます。MQTT 5 では、保持されたメッセージは、設定したメッセージ有効期限が切れると期限切れになります。詳細については、「メッセージの有効期限」を参照してください。 |
永続セッションは、クライアントがタイムアウト期間内に再接続しない場合、期限切れになります。永続セッションの有効期限が切れると、QOS = 1 で発行され、デバイスが切断されている間に QOS = 1 でサブスクライブされたクライアントのサブスクリプションと保存済みメッセージが削除されます。期限切れのメッセージは配信されません。永続的なセッションでのセッションの有効期限の詳細については、「MQTT 永続的セッション」を参照してください。。 |
永続セッションについては、MQTT 永続的セッション を参照してください。
Retreated Messages を使用すると、発行するクライアントは、接続後にメッセージを保持してデバイスに配信するかどうか、デバイスに以前のセッションがあったかどうかを判断します。メッセージを保存する選択は発行者が行い、保存されたメッセージは、QoS 0 または QoS 1 のサブスクリプションでサブスクライブする現在および将来のすべてのクライアントに配信されます。保持されたメッセージで一度に維持できるのは、特定のトピックに関するメッセージ 1 つだけです。
アカウントが保持されるメッセージを最大数保存している場合、 AWS IoT Core は、保持されたメッセージの一部が削除され、保持されたメッセージの数が上限を下回るまで、RETAIN が設定され、ペイロードが 0 バイトを超える状態で発行されたメッセージに対してスロットルされたレスポンスを返します。
MQTT 保持メッセージと AWS IoT デバイスシャドウ
保持されたメッセージとデバイスシャドウのどちらでもデバイスからのデータが保持されますが、どちらも動作が異なり、達成する目的も異なります。このセクションでは、それらの類似点と相違点について説明します。
保持されたメッセージ |
デバイスシャドウ |
|
---|---|---|
メッセージペイロードに事前定義された構造またはスキーマがある |
実装によって定義されている通り。MQTT は、そのメッセージペイロードの構造やスキーマを指定しません。 |
AWS IoT は、特定のデータ構造をサポートします。 |
メッセージペイロードを更新すると、イベントメッセージが生成されます |
保持されたメッセージを発行すると、サブスクライブしているクライアントにメッセージが送信されますが、追加の更新メッセージは生成されません。 |
Device Shadow を更新すると、変更を説明するメッセージを更新します。 |
メッセージの更新に番号が付けられる |
保持されたメッセージには、自動的に番号が付けられません。 | デバイスシャドウドキュメントには、自動のバージョン番号とタイムスタンプがあります。 |
メッセージペイロードは、モノのリソースにアタッチされます |
保持されたメッセージは モノの リソースに添付されません。 |
デバイスシャドウは モノの リソースにアタッチされます。 |
メッセージペイロードの個々の要素の更新 |
メッセージの個々の要素は、メッセージペイロード全体を更新しないと変更できません。 |
デバイスシャドウドキュメントの個々の要素は、デバイスシャドウドキュメント全体を更新しなくても更新できます。 |
クライアントは、サブスクリプションすると直ちにメッセージデータを受信します |
クライアントは、保持メッセージを持つトピックをサブスクライブした後、保持メッセージを自動的に受信します。 |
クライアントはデバイスシャドウ更新にサブスクライブできますが、現在のステータスを意図的にリクエストする必要があります。 |
インデックス作成と検索可能性 |
保持されたメッセージは、検索用にインデックス化されません。 |
フリートインデックス作成は、検索および集計のためにDevice Shadowデータをインデックス化します |
MQTT の Last Will and Testament (LWT) メッセージ
Last Will and Testament (LWT) は MQTT の機能です。LWT を使用すると、クライアントはブローカーがクライアント定義のトピックに発行し、開始されていない切断が発生したときにそのトピックをサブスクライブしているすべてのクライアントに送信するメッセージを指定できます。クライアントが指定するメッセージは LWT メッセージまたは Will メッセージと呼ばれ、クライアントが定義するトピックは Will トピックと呼ばれます。デバイスがブローカーに接続するときに LWT メッセージを指定できます。これらのメッセージは、接続中に Connect Flag bits
フィールドで Will
Retain
フラグを設定することで保持できます。例えば、Will Retain
フラグが 1
に設定されている場合、Will メッセージはブローカーの関連する Will トピックに保存されます。詳細については、「Will メッセージ
ブローカーは、開始されていない切断が発生するまで Will メッセージを保存します。その場合、ブローカーは Will トピックにサブスクライブしているすべてのクライアントにメッセージを発行して切断を通知します。MQTT DISCONNECT メッセージを使用してクライアントが開始した切断により、クライアントがブローカーから切断した場合、ブローカーは保存されている LWT メッセージを発行しません。それ以外の場合は、すべて LWT メッセージが送信されます。ブローカーが LWT メッセージを送信するときの切断シナリオの完全なリストについては、「接続/切断イベント」を参照してください。
connectAttributes の使用
ConnectAttributes
を使用すると、PersistentConnect
や LastWill
などの IAM ポリシーの接続メッセージで使用する属性を指定できます。ConnectAttributes
を使用すると、デフォルトではデバイスに新機能へのアクセスを許可しないポリシーを構築できます。これは、デバイスが侵害された場合に役立ちます。
connectAttributes
でサポートされる機能は以下のとおりです。
PersistentConnect
-
PersistentConnect
機能を使用して、クライアントとブローカー間の接続が中断されたときに、接続中にクライアントが作成したすべてのサブスクリプションを保存します。 LastWill
-
LastWill
機能を使用して、クライアントが予期せず切断したときにメッセージをLastWillTopic
に発行します。
デフォルトでは、ポリシーには非永続的な接続があり、この接続用に渡される属性はありません。永続的な接続が必要な場合は、IAM ポリシーで永続的な接続を指定する必要があります。
ConnectAttributes
例については、接続ポリシーの例を参照してください。
MQTT 5 がサポートしている機能
AWS IoT Core MQTT 5 のサポートは MQTT v5.0 仕様
AWS IoT Core は、次の MQTT 5 機能をサポートしています。
共有サブスクリプション
AWS IoT Core は、MQTT 3 と MQTT 5 の両方の共有サブスクリプションをサポートします。共有サブスクリプションを使用すると、1 つのトピックへのサブスクリプションを複数のクライアントで共有できますが、そのトピックに公開されたメッセージをランダム配信を使って受信できるのは 1 つのクライアントのみです。共有サブスクリプションでは、多数のサブスクライバー間で MQTT メッセージを効果的に負荷分散できます。例えば、同じトピックを発行するデバイスが 1,000 台あり、それらのメッセージを処理するバックエンドアプリケーションが 10 台あるとします。その場合、バックエンドアプリケーションは同じトピックをサブスクライブでき、それぞれが共有トピックにデバイスによって発行されたメッセージをランダムに受信します。これにより、それらのメッセージの負荷を効果的に「共有」できます。共有サブスクリプションでは、回復性も向上します。バックエンドアプリケーションの接続が切断されると、ブローカーはグループ内の残りのサブスクライバーに負荷を分散します。
共有サブスクリプションを使用するには、クライアントは次のように共有サブスクリプションのトピックフィルターをサブスクライブします。
$share/{ShareName}/{TopicFilter}
-
$share
は共有サブスクリプションのトピックフィルターを示すリテラル文字列です。トピックフィルターは$share
で始まる必要があります。 -
{ShareName}
はサブスクライバーのグループが使用する共有名を指定する文字列です。共有サブスクリプションのトピックフィルターは、ShareName
を含み、その後に/
という文字が続く必要があります。{ShareName}
には、/
、+
、または#
などの文字を含めないでください。{ShareName}
の最大サイズは 128 バイトです。 -
{TopicFilter}
は、非共有サブスクリプションとして、同じトピックフィルターの構文に従います。{TopicFilter}
の最大サイズは 256 バイトです。 -
$share/{ShareName}/{TopicFilter}
に必要な 2 つのスラッシュ (/
) は、トピックおよびトピックフィルターのスラッシュの最大数の制限に含まれていません。
同じ {ShareName}/{TopicFilter}
を持つサブスクリプションは、同じ共有サブスクリプショングループに属します。共有サブスクリプショングループは複数作成できますが、グループあたりの共有サブスクリプションの制限を超えないようにしてください。詳細については、AWS 全般のリファレンスの「AWS IoT Core エンドポイントとクォータ」を参照してください。
次の表では、非共有サブスクリプションと共有サブスクリプションを比較しています。
サブスクリプション | 説明 | トピックフィルターの例 |
---|---|---|
非共有サブスクリプション | 各クライアントは、発行されたメッセージを受信するための個別のサブスクリプションを作成します。メッセージがトピックに発行されると、そのトピックのすべてのサブスクライバーがメッセージのコピーを受け取ります。 |
|
共有サブスクリプション | 複数のクライアントが 1 つのトピックへのサブスクリプションを共有できますが、そのトピックに公開されたメッセージをランダム配信で受信できるのは 1 つのクライアントのみです。 |
|
非共有サブスクリプションフロー | 共有サブスクリプションフロー |
---|---|
![]() |
![]() |
共有サブスクリプションを使用する際の重要な注意事項
-
QoS0 サブスクライバーへの発行が失敗すると、再試行は行われず、メッセージは破棄されます。
-
クリーンセッションの QoS1 サブスクライバーへの発行が失敗すると、メッセージはグループ内の別のサブスクライバーに送信され、複数回再試行されます。すべての再試行後に配信に失敗したメッセージは破棄されます。
-
永続セッションの QoS1 サブスクライバーへの発行の試行が、サブスクライバーがオフラインであるために失敗した場合、メッセージはキューに入れられず、グループ内の別のサブスクライバーに送信されます。すべての再試行後に配信に失敗したメッセージは破棄されます。
-
共有サブスクリプションでは、保持されたメッセージは受信されません。
-
共有サブスクリプションにワイルドカード文字 (# または +) が含まれている場合、1 つのトピックに一致する共有サブスクリプションが複数存在する可能性があります。その場合、メッセージブローカーは発行メッセージをコピーし、一致する共有サブスクリプションごとにランダムなクライアントに送信します。共有サブスクリプションのワイルドカード動作は、次の図で説明できます。
この例では、発行中の MQTT トピック
sports/tennis
と一致する共有サブスクリプションが 3 つあります。メッセージブローカーは発行されたメッセージをコピーし、一致する各グループのランダムなクライアントにメッセージを送信します。クライアント 1 とクライアント 2 はサブスクリプション
$share/consumer1/sports/tennis
を共有します。クライアント 3 とクライアント 4 はサブスクリプション
$share/consumer1/sports/#
を共有します。クライアント 5 とクライアント 6 はサブスクリプション
$share/consumer2/sports/tennis
を共有します。
共有サブスクリプションの制限について詳しくは、「AWS 全般のリファレンス」の「AWS IoT Core エンドポイントとクォータ」を参照してください。コンソールの AWS IoT MQTT クライアントを使用して共有サブスクリプションをテストするには、「」を参照してくださいMQTT クライアントで共有サブスクリプションをテストする。 AWS IoT
クリーンスタートとセッションの有効期限
クリーンスタートとセッション有効期限を使用すると、永続セッションをより柔軟に処理できます。クリーンスタートフラグは、既存のセッションを使用せずにセッションを開始する必要があるかどうかを示します。セッションの有効期限間隔は、切断後にセッションを保持する期間を示します。セッションの有効期限間隔は、切断時に変更できます。詳細については、「MQTT 永続的セッション」を参照してください。
すべての ACK の理由コード
理由コードを使用すると、エラーメッセージをより簡単にデバッグまたは処理できます。理由コードは、ブローカーとのやり取りのタイプ (サブスクライブ、発行、確認) に基づいてメッセージブローカーから返されます。詳細については、「MQTT 理由コード」を参照してください。MQTT 理由コードの完全なリストについては、「MQTT v5 の仕様
トピックエイリアス
トピック名は、2 バイトの整数であるトピックエイリアスに置き換えることができます。トピックエイリアスを使用すると、トピック名の送信を最適化して、計測データサービスのデータコストを削減できる可能性があります。 AWS IoT Core には、トピックエイリアスのデフォルト制限が 8 つあります。詳細については、AWS 全般のリファレンスの「AWS IoT Core エンドポイントとクォータ」を参照してください。
メッセージ有効期限
発行されたメッセージには、メッセージの有効期限値を追加できます。これらの値は、メッセージの有効期限を秒単位で表します。その間隔内にメッセージがサブスクライバーに送信されない場合、メッセージは期限切れになり、削除されます。メッセージの有効期限値を設定しない場合、メッセージは期限切れになりません。
アウトバウンドでは、サブスクライバーは有効期限の残り時間を含むメッセージを受信します。例えば、受信した発行メッセージの有効期限が 30 秒で、20 秒後にサブスクライバーにルーティングされた場合、メッセージの有効期限フィールドは 10 に更新されます。サブスクライバーが受信したメッセージの MEI が 0 に更新されている可能性があります。これは、残り時間が 999 ms 以下になるとすぐに 0 に更新されるためです。
では AWS IoT Core、メッセージの最小有効期限間隔は 1 です。クライアント側から間隔を 0 に設定すると、1 に調整されます。メッセージの最大有効期間は 604800 (7 日) です。これより大きい値はすべて最大値に調整されます。
クロスバージョン通信では、メッセージの有効期限切れの動作は、インバウンド発行メッセージの MQTT バージョンによって決定されます。例えば、MQTT5 経由で接続されたセッションから送信されたメッセージの有効期限付きのメッセージは、MQTT3 セッションでサブスクライブされているデバイスでは期限切れになる可能性があります。次の表は、メッセージ有効期限が次のタイプの発行メッセージをどのようにサポートするかを示しています。
メッセージの種類を発行する | メッセージの有効期限間隔 |
---|---|
通常発行 | サーバーが指定された時間内にメッセージの配信に失敗すると、期限切れのメッセージは削除され、サブスクライバーはそのメッセージを受信できなくなります。これには、デバイスが QoS 1 メッセージを発行していない場合などが含まれます。 |
Retain | 保持されたメッセージの有効期限が切れて新しいクライアントがそのトピックをサブスクライブした場合、クライアントはサブスクライブ時にメッセージを受信しません。 |
ラストウィル | ラストウィルメッセージの間隔は、クライアントが接続を切断し、サーバーがラストウィルメッセージをサブスクライバーに配信しようとした後に始まります。 |
キューに追加済みのメッセージ | クライアントがオフラインのときにメッセージ有効期限が設定されたアウトバウンド QoS1 の有効期限が切れても、永続セッションが再開されると、クライアントは期限切れメッセージを受信しません。 |
その他の MQTT 5 の機能
サーバー切断
接続が切断されると、サーバーは事前にクライアントに DISCONNECT を送信して、切断の理由コードを添えて接続の終了を通知できます。
リクエスト/レスポンス
発行者は、受信時に発行者が指定したトピックへの返信を受信者に送信するようリクエストできます。
最大パケットサイズ
クライアントとサーバーは、サポートする最大パケットサイズを個別に指定できます。
ペイロード形式とコンテンツタイプ
メッセージを発行するときのペイロード形式 (バイナリ、テキスト) とコンテンツタイプを指定できます。これらはメッセージの受信者に転送されます。
MQTT 5 プロパティ
MQTT 5 プロパティは、セッションの有効期限やリクエスト/レスポンスパターンなどの MQTT 5 の新機能をサポートするために、MQTT 標準に追加された重要な機能です。では AWS IoT Core、アウトバウンドメッセージのプロパティを転送するルールを作成したり、HTTP Publish を使用して新しいプロパティの一部を含む MQTT メッセージを発行したりできます。
次の表に、 が AWS IoT Core サポートするすべての MQTT 5 プロパティを示します。
プロパティ | 説明 | 入力タイプ | パケット |
---|---|---|---|
ペイロード形式インジケータ | ペイロードが UTF-8 としてフォーマットされているかどうかを示すブール値。 | バイト | PUBLISH、CONNECT |
コンテンツタイプ | ペイロードの内容を説明する UTF-8 文字列。 | UTF-8 文字列 | PUBLISH、CONNECT |
レスポンストピック | 受信者がリクエスト/レスポンスフローの一部として公開すべきトピックを説明する UTF-8 文字列。トピックにはワイルドカード文字を含めないでください。 | UTF-8 文字列 | PUBLISH、CONNECT |
相関データ | リクエストメッセージの送信者が、レスポンスメッセージの対象となるリクエストを識別するために使用するバイナリデータ。 | バイナリ | PUBLISH、CONNECT |
ユーザーのプロパティ | UTF-8 文字列。このプロパティは、1 つのパケットに複数回表示されることがあります。受信者は、送信されたのと同じ順序でキーと値のペアを受け取ります。 | UTF-8 文字列ペア | 接続、発行、ウィルのプロパティ、サブスクライブ、切断、サブスクライブ解除 |
メッセージの有効期限間隔 | メッセージの有効期限を秒単位で表す 4 バイトの整数。存在しない場合、メッセージの有効期限はありません。 | 4 バイト整数 | PUBLISH、CONNECT |
セッションの有効期限間隔 |
セッションの有効期限を秒単位で表す 4 バイトの整数。 は最大 7 日間 AWS IoT Core をサポートし、デフォルトの最大は 1 時間です。設定した値がアカウントの最大値を超える場合、 AWS IoT Core は CONNACK で調整された値を返します。 |
4 バイト整数 | CONNECT、CONNACK、DISCONNECT |
割り当てられたクライアント識別子 | デバイスによってクライアント ID が指定され AWS IoT Core ていない場合に によって生成されるランダムなクライアント ID。ランダムクライアント ID は、現在ブローカーによって管理されている他のセッションでは使用されていない新しいクライアント ID でなければなりません。 | UTF-8 文字列 | CONNACK |
サーバーキープアライブ | サーバーによって割り当てられたキープアライブ時間を表す 2 バイトの整数。クライアントがキープアライブ時間を超えて非アクティブになると、サーバーはクライアントを切断します。 | 2 バイト整数 | CONNACK |
問題情報をリクエストする | 失敗した場合に理由文字列とユーザープロパティのどちらが送信されるかを示すブール値。 | バイト | CONNECT |
最大受信 | PUBACK を受信せずに送信できる PUBLISH QOS > 0 パケットの最大数を表す 2 バイトの整数。 | 2 バイト整数 | CONNECT、CONNACK |
トピックエイリアスの最大数 | この値は、トピックエイリアスとして受け入れられる最大値を示します。デフォルトは 0 です。 | 2 バイト整数 | CONNECT、CONNACK |
最大の QoS | が AWS IoT Core サポートする QoS の最大値。デフォルトは 1 です。 AWS IoT Core は、QoS2 はサポートしていません。 | バイト | CONNACK |
保持可能 |
AWS IoT Core メッセージブローカーが保持されたメッセージをサポートしているかどうかを示すブール値。デフォルト は 1 です。 |
バイト | CONNACK |
最大パケットサイズ | が AWS IoT Core 受け入れて送信する最大パケットサイズ。128 KB を超えることはできません。 | 4 バイト整数 | CONNECT、CONNACK |
ワイルドカードによるサブスクリプションが利用可能 |
AWS IoT Core メッセージブローカーがワイルドカードサブスクリプション利用可能をサポートしているかどうかを示すブール値。デフォルト は 1 です。 |
バイト | CONNACK |
サブスクリプション ID が利用可能 |
AWS IoT Core メッセージブローカーがサブスクリプション識別子 Available をサポートしているかどうかを示すブール値。デフォルトは 0 です。 |
バイト | CONNACK |
MQTT 理由コード
MQTT 5 では、理由コード response によるエラーレポートが改善されています。 は、パケット別にグループ化された次の理由コードを含むがこれらに限定されない理由コードを返 AWS IoT Core す場合があります。MQTT 5 でサポートされている理由コードの完全なリストについては、「MQTT 5 specifications
CONNACK 理由コード | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
値 | 16 進数 | 理由コード名 | 説明 | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
0 | 0x00 | 成功 | 接続を受け入れます。 | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
128 | 0x80 | 未指定のエラー | サーバーは障害の理由を明らかにしたくないか、他の理由コードのいずれにも当てはまりません。 | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
133 | 0x85 | クライアント ID が無効です | クライアント ID は有効な文字列ですが、サーバーでは許可されていません。 | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
134 | 0x86 | ユーザー名またはパスワードが間違っています | サーバーは、クライアントによって指定されたユーザー名またはパスワードを受け入れません。 | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
135 | 0x87 | 権限がありません | クライアントは接続する権限がありません。 | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
144 | 0x90 | トピック名が無効です | ウィルトピック名は正しい形式になっていますが、サーバーでは受け入れられません。 | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
151 | 0x97 | リソースクォータ | 実装または管理で指定されている制限を超過しました。 | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
155 | 0x9B | QoS はサポートされていません | サーバーは Will QoS で設定された QoS をサポートしていません。 |
PUBACK 理由コード | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
値 | 16 進数 | 理由コード名 | 説明 | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
0 | 0x00 | 成功 | メッセージは受け入れられます。QoS 1 メッセージの発行が続行されます。 | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
128 | 0x80 | 未指定のエラー | 受信者は発行を承認しませんが、理由を明らかにしたくないか、他の値のいずれとも一致しません。 | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
135 | 0x87 | 権限がありません | PUBLISH は許可されていません。 | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
144 | 0x90 | トピック名が無効です | トピック名の形式は正しくありませんが、クライアントまたはサーバーでは受け入れられません。 | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
145 | 0x91 | 使用中のパケット識別子 | パケット ID は既に使用されています。これは、クライアントとサーバー間のセッション状態が一致していないことを示している可能性があります。 | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
151 | 0x97 | リソースクォータ | 実装または管理で指定されている制限を超過しました。 |
DISCONNECT 理由コード | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
値 | 16 進数 | 理由コード名 | 説明 | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
129 | 0x81 | 正しい形式でないパケット | 受信したパケットはこの仕様に準拠していません。 | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
130 | 0x82 | プロトコルエラー | 予期しないパケットまたは順不同のパケットが受信されました。 | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
135 | 0x87 | 権限がありません | リクエストは承認されていません。 | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
139 | 0x8B | サーバーのシャットダウン | サーバーはシャットダウン中です。 | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
141 | 0x8D | キープアライブタイムアウト | キープアライブ時間の 1.5 倍の間、パケットが受信されなかったため、接続は閉じられます。 | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
142 | 0x8E | セッションの引き継ぎ | 同じ ClientID を使用する別の接続が接続されたため、この接続は閉じられました。 | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
143 | 0x8F | トピックフィルターが無効です | トピックフィルターは正しく構成されていますが、サーバーでは受け入れられません。 | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
144 | 0x90 | トピック名が無効です | トピック名は正しい形式ですが、このクライアントまたはサーバーでは受け入れられません。 | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
147 | 0x93 | 受信上限を超えました | クライアントまたはサーバーが、PUBACK または PUBCOMP を送信していない発行の受信数が最大受信数を超えています。 | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
148 | 0x94 | トピックのエイリアスが無効です | クライアントまたはサーバーが、CONNECT または CONNACK パケットで送信した最大トピックエイリアスを超えるトピックエイリアスを含む PUBLISH パケットを受信しました。 | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
151 | 0x97 | リソースクォータ | 実装または管理で指定されている制限を超過しました。 | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
152 | 0x98 | 管理アクション | 管理アクションにより接続が切断されました。 | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
155 | 0x9B | QoS はサポートされていません | クライアントが CONNACK の最大 QoS で指定した QoS よりも大きい QoS を指定しました。 | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
161 | 0xA1 | サブスクリプション ID はサポートされていません | サーバーはサブスクリプション ID をサポートしていません。サブスクリプションは受け付けられません。 |
SUBACK 理由コード | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
値 | 16 進数 | 理由コード名 | 説明 | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
0 | 0x00 | 付与された QoS 0 | サブスクリプションが承認され、送信される最大 QoS は QoS 0 になります。これはリクエストされた QoS よりも低い可能性があります。 | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
1 | 0x01 | 付与された QoS 1 | サブスクリプションが承認され、送信される最大 QoS は QoS 1 になります。これはリクエストされた QoS よりも低い可能性があります。 | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
128 | 0x80 | 未指定のエラー | サブスクリプションは受け付けられず、サーバーは理由を明らかにしたくないか、他の理由コードのいずれも適用されません。 | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
135 | 0x87 | 権限がありません | クライアントには、このサブスクライブを行う権限がありません。 | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
143 | 0x8F | トピックフィルターが無効です | トピックフィルターは正しく構成されていますが、このクライアントでは使用できません。 | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
145 | 0x91 | 使用中のパケット識別子 | 指定されたパケット識別子は既に使用されています。 | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
151 | 0x97 | リソースクォータ | 実装または管理で指定されている制限を超過しました。 |
UNSUBACK 理由コード | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
値 | 16 進数 | 理由コード名 | 説明 | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
0 | 0x00 | 成功 | サブスクリプションが削除されます。 | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
128 | 0x80 | 未指定のエラー | サブスクリプション解除を完了できませんでした。サーバーは理由を明らかにしたくないか、他の理由コードのいずれも適用されません。 | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
143 | 0x8F | トピックフィルターが無効です | トピックフィルターは正しく構成されていますが、このクライアントでは使用できません。 | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
145 | 0x91 | 使用中のパケット識別子 | 指定されたパケット識別子は既に使用されています。 |
AWS IoT MQTT 仕様との違い
メッセージブローカーの実装は MQTT v3.1.1 仕様
-
AWS IoT は、MQTT 3 の次のパケットをサポートしていません: PUBREC、PUBREL、PUBCOMP。
-
AWS IoT は、MQTT 5 の次のパケットをサポートしていません: PUBREC、PUBREL、PUBCOMP、AUTH。
-
AWS IoT は MQTT 5 サーバーリダイレクトをサポートしていません。
-
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/temperature
sensor/temperature/room1
に発行されたメッセージを受信しますが、sensor
に発行されたメッセージは受信しません。 ワイルドカードの使用の詳細については、「トピックフィルター」を参照してください。 -
メッセージブローカーは、クライアント ID を使用して、各クライアントを識別します。クライアント ID は MQTT ペイロードの一部としてクライアントからメッセージブローカーに渡されます。クライアント ID が同じ 2 つのクライアントがメッセージブローカーに同時に接続することはできません。あるクライアントが別のクライアントのクライアント ID を使用してメッセージブローカーに接続すると、新しいクライアント接続が受け入れられ、以前に接続されたクライアントは切断されます。
-
まれに、メッセージブローカーは、パケット ID が異なる同じ論理 PUBLISH メッセージを再送信する場合があります。
-
ワイルドカード文字を含むトピックフィルターへのサブスクリプションでは、保持されたメッセージの受信ができません。保持されたメッセージを受信するには、サブスクライブリクエストに、保持されたメッセージのトピックと完全に一致するトピックフィルターが含まれている必要があります。
-
メッセージブローカーはメッセージと ACK の正しい受信順序を確保するわけではありません。
-
AWS IoT には、仕様とは異なる制限がある場合があります。詳細については、AWS IoT リファレンスガイドの「AWS IoT Core メッセージブローカーとプロトコルの制限とクォータ」を参照してください。
-
MQTT DUP フラグはサポートされていません。