MQTT - AWS IoT Core

翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。

MQTT

CONNECT、DISCONNECT、および RECONNECT

「デバイス送信CONNECT先 AWS IoT Core (ハッピーケース)」

テスト対象のデバイスがCONNECTリクエストを送信したことを検証します。

API テストケース定義:

注記

EXECUTION_TIMEOUTのデフォルト値は 5 分です。タイムアウト値は 2 分であることを推奨します。

"tests":[ { "name":"my_mqtt_connect_test", "configuration": { // optional: "EXECUTION_TIMEOUT":"300", // in seconds }, "test":{ "id":"MQTT_Connect", "version":"0.0.0" } } ]
「デバイスは QoS1 の任意のトピックPUBACKに戻ることができます」

このテストケースは、デバイス (クライアント) が QoS1 でトピックをサブスクライブした後にブローカーから発行メッセージを受信した場合にPUBACKメッセージを返すことができるかどうかを確認します。

このテストケースでは、ペイロードコンテンツとペイロードサイズを設定できます。ペイロードサイズが設定されている場合、Device Advisor はペイロードコンテンツの値を上書きし、事前定義済みのペイロードを目的のサイズでデバイスに送信します。ペイロードサイズは 0 から 128 までの値で、128 KB を超えることはできません。AWS IoT Core メッセージブローカーとプロトコルの制限とクォータのページで示されているように、 AWS IoT Core では、128 KB を超えるリクエストの発行および接続は拒否されます。

API テストケース定義:

注記

EXECUTION_TIMEOUTのデフォルト値は 5 分です。タイムアウト値は 2 分を推奨します。PAYLOAD_SIZE は 0~128 KB の値に設定できます。ペイロードサイズを定義すると、Device Advisor が指定されたサイズの事前定義されたペイロードをデバイスに送り返すため、ペイロードコンテンツが上書きされます。

"tests":[ { "name":"my_mqtt_client_puback_qos1", "configuration": { // optional:"TRIGGER_TOPIC": "myTopic", "EXECUTION_TIMEOUT":"300", // in seconds "PAYLOAD_FOR_PUBLISH_VALIDATION":"custom payload", "PAYLOAD_SIZE":"100" // in kilobytes }, "test": { "id": "MQTT_Client_Puback_QoS1", "version": "0.0.0" } } ]
「ジッターバックオフによるデバイス接続の再試行 - CONNACK応答なし」

ブローカーに少なくとも 5 回再接続するときに、テスト対象のデバイスが適切なジッターバックオフを使用することを検証します。ブローカーは、テスト対象のデバイスのタイムスタンプを記録CONNECTし、パケット検証を実行し、テスト対象のCONNACKデバイスに を送信せずに一時停止し、テスト対象のデバイスがリクエストを再送信するのを待ちます。6 回目の接続試行は通過しCONNACK、テスト対象のデバイスにフローバックできます。

上記のプロセスが再び実行されます。合計で、このテストケースでは、デバイスが合計で少なくとも 12 回接続する必要があります。収集されたタイムスタンプは、ジッターバックオフがテスト対象デバイスによって使用されていることを検証するために使用されます。テスト対象のデバイスにエクスポネンシャルバックオフ遅延のみがある場合、警告付きでこのテストケースに合格します。

このテストケースに合格するには、テスト対象のデバイスにエクスポネンシャルバックオフとジッターメカニズムを実装することをお勧めします。

API テストケース定義:

注記

EXECUTION_TIMEOUT のデフォルト値は 5 分です。タイムアウト値は 4 分であることを推奨します。

"tests":[ { "name":"my_mqtt_jitter_backoff_retries_test", "configuration": { // optional: "EXECUTION_TIMEOUT":"300", // in seconds }, "test":{ "id":"MQTT_Connect_Jitter_Backoff_Retries", "version":"0.0.0" } } ]
「エクスポネンシャルバックオフによるデバイス接続の再試行 - CONNACK応答なし」

ブローカーに少なくとも 5 回再接続するときに、テスト対象のデバイスが適切なエクスポネンシャルバックオフを使用することを検証します。ブローカーは、テスト対象のデバイスのタイムスタンプを記録しCONNECT、パケット検証を実行し、CONNACKクライアントデバイスに を送信せずに一時停止し、テスト対象のデバイスがリクエストを再送信するのを待ちます。収集されたタイムスタンプは、エクスポネンシャルバックオフがテスト対象のデバイスによって使用されていることを検証するために使用されます。

このテストケースに合格するには、テスト対象のデバイスにエクスポネンシャルバックオフとジッターメカニズムを実装することをお勧めします。

API テストケース定義:

注記

EXECUTION_TIMEOUT のデフォルト値は 5 分です。タイムアウト値は 4 分であることを推奨します。

"tests":[ { "name":"my_mqtt_exponential_backoff_retries_test", "configuration": { // optional: "EXECUTION_TIMEOUT":"600", // in seconds }, "test":{ "id":"MQTT_Connect_Exponential_Backoff_Retries", "version":"0.0.0" } } ]
「デバイスはジッターバックオフを使用して再接続します-サーバーの切断後」

テスト対象のデバイスが、サーバーから切断された後の再接続時に必要なジッターとバックオフを使用しているかどうかを検証します。Device Advisor は、デバイスをサーバーから少なくとも 5 回切断し、デバイスの動作を観察してMQTT再接続します。Device Advisor は、テスト対象のデバイスのCONNECTリクエストのタイムスタンプを記録CONNACKし、パケット検証を実行し、クライアントデバイスに を送信せずに一時停止し、テスト対象のデバイスがリクエストを再送信するのを待ちます。収集されたタイムスタンプは、テスト対象デバイスが再接続中にジッターとバックオフを使用することを検証するために使用されます。テスト対象のデバイスがエクスポネンシャルバックオフのみを使用している、または適切なジッターバックオフメカニズムを実装していない場合は、警告付きでこのテストケースに合格します。テスト対象のデバイスが、線形バックオフまたは固定バックオフメカニズムを実装している場合、テストは失敗します。

このテストケースに合格するには、テスト対象のデバイスに、エクスポネンシャルバックオフとジッターメカニズムを実装することをお勧めします。

API テストケース定義:

注記

EXECUTION_TIMEOUT のデフォルト値は 5 分です。タイムアウト値は 4 分であることを推奨します。

バックオフを検証する再接続試行回数は、RECONNECTION_ATTEMPTS を指定する事によって変更できます。その数は 5~10 の間である必要があります。デフォルト値は 5 です。

"tests":[ { "name":"my_mqtt_reconnect_backoff_retries_on_server_disconnect", "configuration":{ // optional: "EXECUTION_TIMEOUT":"300", // in seconds "RECONNECTION_ATTEMPTS": 5 }, "test":{ "id":"MQTT_Reconnect_Backoff_Retries_On_Server_Disconnect", "version":"0.0.0" } } ]
「ジッターバックオフを使用したデバイスの再接続 - 不安定な接続時」

不安定な接続での再接続中に、テスト対象のデバイスが必要なジッターとバックオフを使用するかどうかを検証します。Device Advisor は、5 回の正常な接続後にデバイスをサーバーから切断し、デバイスの動作を観察してMQTT再接続します。Device Advisor は、テスト対象のデバイスのCONNECTリクエストのタイムスタンプを記録し、パケット検証を実行し、 を送り返しCONNACK、切断し、切断のタイムスタンプを記録し、テスト対象のデバイスがリクエストを再送信するのを待ちます。収集されたタイムスタンプは、テスト対象デバイスが、接続は成功したが不安定になった後の再接続中にジッターとバックオフを使用していることを検証するために使用されます。テスト対象のデバイスがエクスポネンシャルバックオフのみを使用している、または適切なジッターバックオフメカニズムを実装していない場合は、警告付きでこのテストケースに合格します。テスト対象のデバイスが、線形バックオフまたは固定バックオフメカニズムを実装している場合、テストは失敗します。

このテストケースに合格するには、テスト対象のデバイスに、エクスポネンシャルバックオフとジッターメカニズムを実装することをお勧めします。

API テストケース定義:

注記

EXECUTION_TIMEOUT のデフォルト値は 5 分です。タイムアウト値は 4 分であることを推奨します。

バックオフを検証する再接続試行回数は、RECONNECTION_ATTEMPTS を指定する事によって変更できます。その数は 5~10 の間である必要があります。デフォルト値は 5 です。

"tests":[ { "name":"my_mqtt_reconnect_backoff_retries_on_unstable_connection", "configuration":{ // optional: "EXECUTION_TIMEOUT":"300", // in seconds "RECONNECTION_ATTEMPTS": 5 }, "test":{ "id":"MQTT_Reconnect_Backoff_Retries_On_Unstable_Connection", "version":"0.0.0" } } ]

公開

「QoS0 (Happy Case)」

テスト対象のデバイスが QoS0 または QoS1 でメッセージを発行することを検証します。テスト設定でトピック値とペイロードを指定することで、メッセージとペイロードのトピックを検証することもできます。

注記

EXECUTION_TIMEOUTのデフォルト値は 5 分です。タイムアウト値は 2 分であることを推奨します。

"tests":[ { "name":"my_mqtt_publish_test", "configuration":{ // optional: "EXECUTION_TIMEOUT":"300", // in seconds "TOPIC_FOR_PUBLISH_VALIDATION": "my_TOPIC_FOR_PUBLISH_VALIDATION", "PAYLOAD_FOR_PUBLISH_VALIDATION": "my_PAYLOAD_FOR_PUBLISH_VALIDATION", }, "test":{ "id":"MQTT_Publish", "version":"0.0.0" } } ]
QoS1 パブリッシュ再試行 - いいえPUBACK」

ブローカーが を送信しない場合、テスト対象のデバイスが QoS1 で送信されたメッセージを再発行することを検証しますPUBACK。また、テスト設定でこのトピックを指定することで、メッセージのトピックを検証することもできます。メッセージを再発行する前に、クライアントデバイスを切断しないでください。このテストでは、再発行されたメッセージが、元のメッセージと同じパケット ID を持つことも検証されます。テスト実行中にデバイスが接続を失って再接続した場合、テストケースは失敗することなくリセットされます。そのため、デバイスはテストケースのステップを再実行する必要があります。

API テストケース定義:

注記

EXECUTION_TIMEOUTのデフォルト値は 5 分です。少なくとも 4 分間お勧めします。

"tests":[ { "name":"my_mqtt_publish_retry_test", "configuration":{ // optional: "EXECUTION_TIMEOUT":"300", // in seconds "TOPIC_FOR_PUBLISH_VALIDATION": "my_TOPIC_FOR_PUBLISH_VALIDATION", "PAYLOAD_FOR_PUBLISH_VALIDATION": "my_PAYLOAD_FOR_PUBLISH_VALIDATION", }, "test":{ "id":"MQTT_Publish_Retry_No_Puback", "version":"0.0.0" } } ]
「保持されたメッセージの発行」

テスト対象のデバイスが、retainFlag が true に設定されたメッセージを発行することを検証します。テスト設定でトピック値とペイロードを設定することで、メッセージのトピックとペイロードを検証できます。PUBLISH パケット内でretainFlag送信された が true に設定されていない場合、テストケースは失敗します。

API テストケース定義:

注記

EXECUTION_TIMEOUTのデフォルト値は 5 分です。タイムアウト値は 2 分であることを推奨します。このテストケースを実行するには、デバイスロールiot:RetainPublish アクションを追加します。

"tests":[ { "name":"my_mqtt_publish_retained_messages_test", "configuration":{ // optional: "EXECUTION_TIMEOUT":"300", // in seconds "TOPIC_FOR_PUBLISH_RETAINED_VALIDATION": "my_TOPIC_FOR_PUBLISH_RETAINED_VALIDATION", "PAYLOAD_FOR_PUBLISH_RETAINED_VALIDATION": "my_PAYLOAD_FOR_PUBLISH_RETAINED_VALIDATION", }, "test":{ "id":"MQTT_Publish_Retained_Messages", "version":"0.0.0" } } ]
「ユーザープロパティを使用して発行」

テスト対象デバイスが正しいユーザープロパティでメッセージを発行することを検証します。テスト設定で名前と値のペアを設定することで、ユーザープロパティを検証できます。ユーザープロパティが指定されていないか、一致しない場合、テストケースは失敗します。

API テストケース定義:

注記

これはMQTT5唯一のテストケースです。

EXECUTION_TIMEOUTのデフォルト値は 5 分です。タイムアウト値は 2 分であることを推奨します。

"tests":[ { "name":"my_mqtt_user_property_test", "test":{ "USER_PROPERTIES": [ {"name": "name1", "value":"value1"}, {"name": "name2", "value":"value2"} ], "EXECUTION_TIMEOUT":"300", // in seconds }, "test":{ "id":"MQTT_Publish_User_Property", "version":"0.0.0" } } ]

Subscribe

「Can Subscribe (Happy Case)」

テスト対象のデバイスがMQTTトピックをサブスクライブしていることを検証します。テスト設定でこのトピックを指定することで、テスト対象のデバイスがサブスクライブするトピックを検証することもできます。

API テストケース定義:

注記

EXECUTION_TIMEOUTのデフォルト値は 5 分です。タイムアウト値は 2 分であることを推奨します。

"tests":[ { "name":"my_mqtt_subscribe_test", "configuration":{ // optional: "EXECUTION_TIMEOUT":"300", // in seconds "TOPIC_LIST_FOR_SUBSCRIPTION_VALIDATION":["my_TOPIC_FOR_PUBLISH_VALIDATION_a","my_TOPIC_FOR_PUBLISH_VALIDATION_b"] }, "test":{ "id":"MQTT_Subscribe", "version":"0.0.0" } } ]
「サブスクライブ再試行 - いいえSUBACK」

テスト対象のデバイスが失敗したMQTTトピックのサブスクリプションを再試行することを確認します。その後、サーバーは を待機し、送信しませんSUBACK。クライアントデバイスがサブスクリプションを再試行しない場合、テストは失敗します。クライアントデバイスは、失敗したサブスクリプションを同じパケット ID で再試行する必要があります。テスト設定でこのトピックを指定することで、テスト対象のデバイスがサブスクライブするトピックを検証することもできます。テスト実行中にデバイスが接続を失って再接続した場合、テストケースは失敗することなくリセットされます。そのため、デバイスはテストケースのステップを再実行する必要があります。

API テストケース定義:

注記

EXECUTION_TIMEOUT のデフォルト値は 5 分です。タイムアウト値は 4 分であることを推奨します。

"tests":[ { "name":"my_mqtt_subscribe_retry_test", "configuration":{ "EXECUTION_TIMEOUT":"300", // in seconds // optional: "TOPIC_LIST_FOR_SUBSCRIPTION_VALIDATION":["myTOPIC_FOR_PUBLISH_VALIDATION_a","my_TOPIC_FOR_PUBLISH_VALIDATION_b"] }, "test":{ "id":"MQTT_Subscribe_Retry_No_Suback", "version":"0.0.0" } } ]

Keep-Alive

「Mqtt No Ack PingResp」

このテストケースでは、テスト対象のデバイスが ping 応答を受信しないときに切断されるかどうかを検証します。このテストケースの一環として、Device Advisor は発行、サブスクライブ、ping リクエスト AWS IoT Core のために から送信されたレスポンスをブロックします。また、テスト対象のデバイスがMQTT接続を切断するかどうかも検証します。

API テストケース定義:

注記

EXECUTION_TIMEOUTのデフォルト値は 5 分です。タイムアウトは keepAliveTime 値の 1.5 倍超とすることをお勧めします。

このテストでは、最大値は 230 秒以下にkeepAliveTimeする必要があります。

"tests":[ { "name":"Mqtt No Ack PingResp", "configuration": //optional: "EXECUTION_TIMEOUT":"306", // in seconds }, "test":{ "id":"MQTT_No_Ack_PingResp", "version":"0.0.0" } } ]

永続セッション

「永続セッション (Happy Case)」

このテストケースは、永続セッションから切断されたときのデバイスの動作を検証します。テストケースは、デバイスの再接続、明示的な再サブスクライブなしでのトリガートピックへのサブスクライブの再開、トピックに保存済みのメッセージの受信、および永続セッション中に期待どおりの動作が可能かどうかをチェックします。このテストケースが合格すると、クライアントデバイスが AWS IoT Core ブローカーとの永続的なセッションを期待される方法で維持できることを示します。永 AWS IoT 続セッションの詳細については、「永MQTT続セッションの使用」を参照してください。

このテストケースでは、クライアントデバイスは、クリーンセッションフラグを false に設定CONNECT AWS IoT Core して を に設定し、トリガートピックをサブスクライブすることが期待されます。サブスクリプションが成功すると、デバイスは AWS IoT Core Device Advisor によって切断されます。デバイスが切断状態の間、そのトピックに QoS 1 メッセージペイロードが保存されます。その後、Device Advisor は、クライアントデバイスがテストエンドポイントとの再接続を許可します。この時点で、永続的なセッションがあるため、クライアントデバイスは追加のSUBSCRIBEパケットを送信せずにトピックサブスクリプションを再開し、ブローカーから QoS 1 メッセージを受信することが期待されます。再接続後、クライアントデバイスが追加のSUBSCRIBEパケットを送信してトリガートピックに再サブスクライブした場合、および/またはクライアントがトリガートピックから保存されたメッセージを受信できなかった場合、テストケースは失敗します。

API テストケース定義:

注記

EXECUTION_TIMEOUTのデフォルト値は 5 分です。タイムアウト値は 4 分以上にすることを推奨します。最初の接続で、クライアントデバイスは、以前サブスクライブされていなかった TRIGGER_TOPIC に明示的にサブスクライブする必要があります。テストケースに合格するには、クライアントデバイスが QoS 1 で TRIGGER_TOPIC に正常にサブスクライブする必要があります。再接続後、クライアントデバイスはアクティブな永続セッションがあることを理解することが期待されます。そのため、トリガートピックによって送信された保存されたメッセージを受け入れ、その特定のメッセージPUBACKに対して返す必要があります。

"tests":[ { "name":"my_mqtt_persistent_session_happy_case", "configuration":{ //required: "TRIGGER_TOPIC": "myTrigger/topic", // optional: // if Payload not provided, a string will be stored in the trigger topic to be sent back to the client device "PAYLOAD": "The message which should be received from AWS IoT Broker after re-connecting to a persistent session from the specified trigger topic.", "EXECUTION_TIMEOUT":"300" // in seconds }, "test":{ "id":"MQTT_Persistent_Session_Happy_Case", "version":"0.0.0" } } ]
「永続セッション - セッションの有効期限」

このテストケースは、切断されたデバイスが期限切れの永続セッションに再接続するときのデバイスの動作を検証するのに役立ちます。セッションの有効期限が切れると、デバイスは新しいSUBSCRIBEパケットを明示的に送信することで、以前にサブスクライブしたトピックに再サブスクライブすることが期待されます。

最初の接続中、テストデバイスは AWS IoT ブローカーCONNECTで になることが予想されます。これは、永続セッションを開始するフラグCleanSessionが false に設定されているためです。その後、デバイスはトリガートピックをサブスクライブする必要があります。次に、サブスクリプションが成功し、永続セッションが開始されると、デバイスは AWS IoT Core Device Advisor によって切断されます。切断後、 AWS IoT Core Device Advisor はテストデバイスがテストエンドポイントと再接続できるようにします。この時点で、テストデバイスが別のCONNECTパケットを送信すると、 AWS IoT Core Device Advisor は永続セッションの有効期限が切れたことを示すCONNACKパケットを送り返します。テストデバイスはこのパケットを適切に解釈する必要があり、永続セッションが終了すると、同じトリガートピックに再サブスクライブすることが予期されます。テストデバイスがトピックトリガーに再サブスクライブしない場合、テストケースは失敗します。テストに合格するには、デバイスは永続セッションが終了したことを理解し、2 番目の接続で同じトリガートピックの新しいSUBSCRIBEパケットを返送する必要があります。

テストデバイスでこのテストケースに合格した場合、永続セッションの期限が切れる際に、デバイスが予期された方法で再接続を処理できることを示しています。

API テストケース定義:

注記

EXECUTION_TIMEOUTのデフォルト値は 5 分です。タイムアウト値は 4 分以上にすることを推奨します。クライアントデバイスは、以前サブスクライブされていなかった TRIGGER_TOPIC に明示的にサブスクライブする必要があります。テストケースに合格するには、テストデバイスはCleanSessionフラグを false に設定してCONNECTパケットを送信し、QoS 1 のトリガートピックに正常にサブスクライブする必要があります。接続が成功すると、 AWS IoT Core Device Advisor はデバイスを切断します。切断後、 AWS IoT Core Device Advisor はデバイスの再接続を許可し、 AWS IoT Core Device Advisor は永続セッションを終了していたTRIGGER_TOPICため、デバイスは同じ に再サブスクライブすることが期待されます。

"tests":[ { "name":"my_expired_persistent_session_test", "configuration":{ //required: "TRIGGER_TOPIC": "myTrigger/topic", // optional: "EXECUTION_TIMEOUT":"300" // in seconds }, "test":{ "id":"MQTT_Expired_Persistent_Session", "version":"0.0.0" } } ]