翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。
# ダイレクトメッセージング
AWS IoT Core で Direct Messaging がサポートされるようになりました。1 つの接続デバイスに MQTT クライアント ID でメッセージを送信できます。デバイスがトピックをサブスクライブする必要はありません。
以前は、特定のデバイスにメッセージを送信するには、デバイスがサブスクライブしたトピックに発行する必要がありましたが、配信を確認する組み込みの方法はありませんでした。送信者は SendDirectMessage HTTP API を呼び出し、受信者のクライアント ID とターゲットトピックを指定します。の場合`confirmation=true`、 は QoS 1 で AWS IoT Core 配信し、レシーバーの PUBACK を待ってから正常なレスポンスを返します。これにより、end-to-endの配信確認が提供されます。API レスポンスと Amazon CloudWatch Logs は、配信ステータスと障害の理由を完全に可視化します。
ダイレクトメッセージはルール実行の AWS IoT ルールによって処理されず、オフラインデバイスのキューに入れられず、保持されたメッセージもサポートされません。
**Topics**
+ [前提条件](#direct-messaging-prerequisites)
+ [SendDirectMessage API](#direct-messaging-api)
+ [レシーバークライアントの動作](#direct-messaging-receiver)
## 前提条件
送信者と受信者の両方がダイレクトメッセージングを使用するには、特定のポリシーアクションが必要です。送信者には アクセス`iot:SendDirectMessage`許可が必要です。ターゲットクライアント ID は リソースとして指定され、`iot:Topic`条件キー (オプション) は送信者が直接メッセージを送信できるトピックを制限します。受信者には、ターゲットトピックに対する`iot:Receive`アクセス許可が必要です。受信者は`iot:Subscribe`アクセス許可を必要としません。トピックのサブスクリプションを必要とせずにダイレクトメッセージを AWS IoT Core 配信します。ポリシーの詳細と例については、「」を参照してください[ダイレクトメッセージングポリシーの例](direct-messaging-policy-examples.md)。
HTTP リクエストで使用される認証およびポートマッピングについては、「[プロトコル、ポートマッピング、認証](protocols.md#protocol-mapping)」を参照してください。
## SendDirectMessage API
送信者は、HTTP POST リクエストをクライアント固有の URL に送信することで、ダイレクトメッセージを送信できます。
```
https://{{IoT_data_endpoint}}/connections/{{client_id}}/messages?topic={{topic_name}}&confirmation=true&timeout=10
```
+ {{IoT\_data\_endpoint}} は、[AWS IoT デバイスのデータエンドポイント](iot-connect-devices.md#iot-connect-device-endpoints)です。エンドポイントを検索する[AWS IoT デバイスデータとサービスエンドポイント](iot-connect-devices.md#iot-connect-device-endpoints)には、「」を参照してください。
+ {{client\_id}} は、メッセージを送信する MQTT クライアントの一意の識別子です。クライアント IDsは 128 文字を超えてはならず、ドル記号 ($) で始めることはできません。MQTT クライアント IDsには、スペース、スラッシュ (/)、UTF-8 文字など、HTTP リクエストで無効な文字が含まれている場合、URL エンコード (パーセントエンコード) する必要があります。詳細については、[AWS IoT Core 「メッセージブローカーとプロトコルの制限とクォータ](https://docs.aws.amazon.com/general/latest/gr/iot-core.html#message-broker-limits)」を参照してください。
+ {{topic\_name}} は、受信者がメッセージを受信するトピックで、URL エンコードされています。$ で始めることはできません。 AWS IoT Core 予約済みトピックにすることはできません。トピックの長さと深さの制限については、 AWS IoT Core 「サービスクォータ」ページを参照してください。詳細については、[AWS IoT Core 「メッセージブローカーとプロトコルの制限とクォータ](https://docs.aws.amazon.com/general/latest/gr/iot-core.html#message-broker-limits)」を参照してください。
+ {{確認}}はブール値です。に設定すると`true`、API は QoS 1 でメッセージを配信し、MQTT クライアントが配信確認 (PUBACK) を送信するのを待ってから、成功したレスポンスを返します。指定されたタイムアウト期間内に配信確認が受信されない場合、API は HTTP 504 を返します。
+ {{timeout}} は、メッセージの配信後に受信側クライアントからの配信確認 (PUBACK) を待機する最大時間を秒単位で表す整数です。このパラメータは、 `confirmation` が に設定されている場合にのみ使用されます`true`。`confirmation` が の場合`false`、このパラメータは無視されます。内部処理のため、合計 API 応答時間がこの値よりも長くなる可能性があります。HTTP クライアントのタイムアウトをこのパラメータより大きい値に設定します。
### API レスポンスのステータスコード
次の表に、SendDirectMessage API によって返される HTTP ステータスコードと、それぞれの推奨アクションを示します。 AWS IoT Core CloudWatch ログを有効にして、プログラムによるエラー処理の理由フィールドを含む詳細な SendDirectMessage イベントログを表示します。
**SendDirectMessage API レスポンスステータスコード**
| HTTP コード | 推奨されるアクション |
| --- | --- |
| 200 OK | で配信確認がリクエストされた場合confirmation=true、受信者がメッセージ受信を確認したことを示します。それ以外の場合は、メッセージが正常にディスパッチされたことを示します。 |
| 400 Bad Request | これは、いずれかのパラメータが無効であることを意味します。HTTP レスポンスメッセージまたは CloudWatch ログを確認して、特定の障害を特定して修正します。トピック名と Client-id が有効で、URL が正しくエンコードされていることを確認します。 |
| 403 Forbidden | つまり、送信者のポリシーはターゲットクライアントとトピックiot:SendDirectMessageに対して を許可しないか、受信者のポリシーはトピックiot:Receiveに対して を許可しません。HTTP レスポンスメッセージまたは CloudWatch ログを確認して特定の障害を特定し、対応するポリシーを更新します。「[ダイレクトメッセージングポリシーの例](direct-messaging-policy-examples.md)」を参照してください。 |
| 404 Not Found | これは、ターゲットクライアント ID が接続されていないことを意味します AWS IoT Core。特定の理由で HTTP レスポンスメッセージまたは CloudWatch ログを確認し、レシーバーが接続されていることを確認して、もう一度試してください。レスポンスメッセージに「ターゲットクライアント ID は接続されていませんが、アクティブな永続セッションがあります」と表示されている場合、ターゲットクライアントには有効期限が切れていない永続セッションがありますが、現在オフラインです。 |
| 413 ペイロードが大きすぎる | ペイロードが最大許容サイズを超えています。ペイロードサイズを減らして再試行します。「[AWS IoT Core サービスのクオータ](https://docs.aws.amazon.com/general/latest/gr/iot-core.html)」を参照してください。 |
| 429 Too Many Requests | これは、アカウントが 1 秒あたりの SendDirectMessage リクエスト数の制限を超えたか、レシーバー接続がアウトバウンドパブリッシュの制限を超えたことを意味します。 requests-per-second 特定の理由で HTTP レスポンスメッセージまたは CloudWatch ログを確認し、リクエストレートを減らし、エクスポネンシャルバックオフを実装します。「[AWS IoT Core サービスのクオータ](https://docs.aws.amazon.com/general/latest/gr/iot-core.html)」を参照してください。 |
| 500 Internal Server Error | これは、予期しないサーバー側のエラーを示します。エクスポネンシャルバックオフを使用してリクエストを再試行します。問題が解決しない場合は、レスポンスの traceId を使用して AWS サポートにお問い合わせください。 |
| 504 ゲートウェイタイムアウト | つまり、レシーバーは指定されたタイムアウト期間内に PUBACK を送信しませんでした。タイムアウト値を増やし、レシーバーの MQTT クライアントが QoS 1 メッセージの PUBACK を送信するか、レシーバーがメッセージをゆっくり処理しているかどうかを確認します。 |
### 例
------
#### [ AWS CLI ]
```
aws iot-data send-direct-message \
--client-id myDevice \
--topic commands/reboot \
--confirmation \
--timeout 10 \
--payload '{"action": "reboot"}' \
--cli-binary-format raw-in-base64-out \
--region us-west-2 \
--endpoint-url https://{{IoT_data_endpoint}}
```
AWS Command Line Interface バージョン 2 を使用している場合は、 `--cli-binary-format`オプションが必要です。これをデフォルト設定にするには、`aws configure set cli-binary-format raw-in-base64-out` を実行します。詳細については、「*AWS Command Line Interface バージョン 2 用ユーザーガイド*」の「[AWS CLI でサポートされているグローバルコマンドラインオプション](https://docs.aws.amazon.com/cli/latest/userguide/cli-configure-options.html#cli-configure-options-list)」を参照してください。
------
#### [ curl (X.509 client certificate, port 8443) ]
```
curl --tlsv1.2 \
--cacert Amazon-root-CA-1.pem \
--cert device.pem.crt \
--key private.pem.key \
--request POST \
--data '{"action": "reboot"}' \
"https://{{IoT_data_endpoint}}:8443/connections/myDevice/messages?topic=commands%2Freboot&confirmation=true&timeout=10"
```
------
## レシーバークライアントの動作
Direct Messaging は、トピックのサブスクリプションを必要とせずに MQTT クライアント (受信者) にメッセージを配信します。Direct Messaging を最大限に活用するには、受信者は次の動作をサポートする必要があります。
+ **明示的にサブスクライブされていないトピックに関するメッセージの受信** — レシーバーのダイレクトメッセージングは、レシーバーが明示的にサブスクライブしていないトピックにメッセージを配信できます。ただし、一部の MQTT クライアント実装では、サブスクライブされていないトピックのメッセージをフィルタリングまたは破棄します。クライアントがこれらのメッセージを破棄した場合、ダイレクトメッセージングは受信者もサブスクライブしているトピックでのみ機能します。任意のトピックでダイレクトメッセージを受信するには、クライアントのメッセージハンドラーがサブスクリプションの状態に関係なくメッセージを処理していることを確認します。
+ **API によって決定される QoS の処理** — 配信されるメッセージの QoS レベルは、受信者のサブスクリプションではなく、送信者の API リクエストの `confirmation`パラメータによって設定されます。の場合`confirmation=true`、メッセージが QoS 1 に到着し、レシーバーのクライアントは PUBACK を送信して配信を確認する必要があります。の場合`confirmation=false`、メッセージは確認なしで QoS 0 に到着します。クライアントの MQTT 実装が QoS 0 と QoS 1 の両方の受信メッセージを正しく処理していることを確認します。