Las traducciones son generadas a través de traducción automática. En caso de conflicto entre la traducción y la version original de inglés, prevalecerá la version en inglés.
Mensajería directa
AWS IoT Core ahora es compatible con la mensajería directa. Puede enviar un mensaje a un único dispositivo conectado mediante su ID de cliente MQTT, sin necesidad de que el dispositivo se suscriba a un tema.
Anteriormente, enviar un mensaje a un dispositivo específico requería publicarlo en un tema al que el dispositivo estaba suscrito, sin una forma integrada de confirmar la entrega. El remitente llama a la API SendDirectMessage HTTP y especifica el ID de cliente del destinatario y un tema de destino. Cuandoconfirmation=true, AWS IoT Core realiza la entrega con QoS 1 y espera a que el receptor reciba el PUBAK antes de devolver una respuesta correcta. Esto te proporciona un acuse de recibo de entrega de principio a fin. La respuesta de la API y CloudWatch los registros de Amazon proporcionan una visibilidad completa del estado de la entrega y los motivos del error.
Las AWS IoT reglas para la ejecución de las reglas no procesan los mensajes directos, no se ponen en cola para los dispositivos sin conexión y no admiten la retención de mensajes.
Requisitos previos
Tanto el remitente como el receptor requieren acciones políticas específicas para utilizar la mensajería directa. El remitente debe tener iot:SendDirectMessage permiso. El identificador del cliente de destino se especifica como recurso y la clave de iot:Topic condición (opcional) restringe los temas a los que un remitente puede enviar mensajes directos. El destinatario debe tener iot:Receive permiso sobre el tema de destino. El receptor no necesita iot:Subscribe permiso: AWS IoT Core envía mensajes directos sin necesidad de suscribirse al tema. Para obtener más información y ejemplos de políticas, consulteEjemplos de políticas de mensajería directa.
Para obtener información sobre la autenticación y las asignaciones de puertos utilizados por las solicitudes HTTP, consulte Protocolos, asignaciones de puertos y autenticación.
SendDirectMessage API
Los remitentes pueden enviar mensajes directos realizando solicitudes HTTP POST a una URL específica del cliente:
https://IoT_data_endpoint/connections/client_id/messages?topic=topic_name&confirmation=true&timeout=10
-
IoT_data_endpointes el punto final de datos del AWS IoT dispositivo. Consulte AWS IoT dispositivos, datos y puntos finales de servicio para encontrar su terminal. -
client_ides el identificador único del cliente MQTT al que enviar el mensaje. Los ID de cliente no deben superar los 128 caracteres y no pueden empezar con el signo de dólar ($). Los ID de cliente de MQTT deben estar codificados en URL (codificación porcentual) cuando contienen caracteres que no son válidos en las solicitudes HTTP, como espacios, barras diagonales (/) y caracteres. UTF-8 Para obtener más información, consulta los límites y cuotas del intermediario de AWS IoT Core mensajes y del protocolo. -
topic_namees el tema sobre el que el receptor recibe el mensaje, URL-encoded. No debe empezar por $. No debe ser un tema AWS IoT Core reservado. Consulta la página de cuotas AWS IoT Core de servicio para conocer los límites de longitud y profundidad de los temas. Para obtener más información, consulta los límites y cuotas del gestor de AWS IoT Core mensajes y de los protocolos. -
confirmationes un booleano. Cuando se establece entrue, la API entrega el mensaje en QoS 1 y espera a que el cliente MQTT envíe una confirmación de entrega (PUBACK) antes de devolver una respuesta satisfactoria. Si la confirmación de entrega no se recibe dentro del período de tiempo de espera especificado, la API devuelve HTTP 504. -
timeoutes un número entero que representa el tiempo máximo, en segundos, para esperar una confirmación de entrega (PUBACK) del cliente receptor una vez entregado el mensaje. Este parámetro solo se usa cuandoconfirmationestá establecido en.trueSiconfirmationes asífalse, este parámetro se ignora. El tiempo total de respuesta de la API puede ser superior a este valor debido al procesamiento interno. Establezca el tiempo de espera del cliente HTTP en un valor superior a este parámetro.
Códigos de estado de respuesta de la API
En la siguiente tabla se enumeran los códigos de estado HTTP devueltos por la SendDirectMessage API y las acciones recomendadas para cada uno de ellos. Habilite AWS IoT Core CloudWatch los registros para ver los registros de SendDirectMessage eventos detallados, incluido el campo de motivo para la gestión de errores programáticos.
| Código de HTTP | Acción recomendada |
|---|---|
| 200 OK | Si se solicitó la confirmación de entrega conconfirmation=true, esto indica que el destinatario ha acuse recibo del mensaje. De lo contrario, esto indica que el mensaje se envió correctamente. |
| 400: solicitud maligna | Esto significa que uno de los parámetros no es válido. Revise el mensaje de respuesta HTTP o CloudWatch los registros para identificar un error específico y corregirlo. Asegúrese de que el nombre del tema y el tema Client-id sean válidos y URL-encoded correctos. |
| 403: prohibido | Esto significa que la política del remitente no cumple con iot:SendDirectMessage el cliente y el tema de destino, o que la política del destinatario no lo hace con iot:Receive respecto al tema. Revisa el mensaje o los CloudWatch registros de respuesta HTTP para identificar un error específico y actualiza la política correspondiente. Consulte Ejemplos de políticas de mensajería directa. |
| 404 Not Found (No encontrado) | Esto significa que el ID del cliente de destino no está conectado AWS IoT Core. Revise el mensaje de respuesta HTTP o CloudWatch los registros para determinar el motivo específico, compruebe que el receptor esté conectado e inténtelo de nuevo. Si el mensaje de respuesta dice «El ID del cliente de destino no está conectado, pero tiene una sesión persistente activa», significa que el cliente de destino tiene una sesión persistente que no ha caducado, pero actualmente está desconectado. |
| 413 La carga útil es demasiado grande | La carga útil supera el tamaño máximo permitido. Reduzca el tamaño de la carga útil y vuelva a intentarlo. Consulte cuotas de AWS IoT Core servicio. |
| 429 Demasiadas solicitudes | Esto significa que la cuenta ha superado el límite de SendDirectMessage solicitudes por segundo o que la conexión del receptor ha superado el límite de publicaciones salientes. Revisa los mensajes de respuesta HTTP o CloudWatch los registros para determinar el motivo específico, reduce la tasa de solicitudes e implementa un retraso exponencial. Consulte cuotas de AWS IoT Core servicio. |
| 500 Error de servidor interno | Esto indica un error inesperado en el servidor. Vuelva a intentar la solicitud con un retraso exponencial. Si el problema persiste, ponte en contacto con el servicio de AWS asistencia con el identificador de seguimiento que aparece en la respuesta. |
| 504 Gateway Timeout | Esto significa que el receptor no envió el PUBACK dentro del período de tiempo de espera especificado. Aumente el valor del tiempo de espera, verifique que el cliente MQTT del receptor envíe mensajes de PUBACK para QoS 1 o compruebe si el receptor procesa los mensajes con lentitud. |
Ejemplos
Comportamiento del cliente receptor
La mensajería directa envía los mensajes a los clientes (receptores) de MQTT sin necesidad de una suscripción temática. Para aprovechar al máximo la mensajería directa, el destinatario debe soportar los siguientes comportamientos:
-
Reciba mensajes sobre temas a los que no se haya suscrito explícitamente: la mensajería directa del destinatario puede enviar mensajes sobre temas a los que el destinatario no se haya suscrito explícitamente. Sin embargo, algunas implementaciones de clientes de MQTT filtran o descartan los mensajes sobre temas en los que se ha cancelado la suscripción. Si su cliente descarta estos mensajes, la mensajería directa solo funcionará en los temas a los que el destinatario también se haya suscrito. Para recibir mensajes directos sobre cualquier tema, comprueba que el gestor de mensajes de tu cliente procese los mensajes independientemente del estado de la suscripción.
-
Gestione la QoS determinada por la API: el nivel de QoS del mensaje entregado lo establece el
confirmationparámetro de la solicitud de API del remitente, no la suscripción del destinatario. En ese momentoconfirmation=true, el mensaje llega a la QoS 1 y el cliente del destinatario debe enviar un PUBAK para confirmar la entrega. Cuandoconfirmation=false, el mensaje llega a QoS 0 sin necesidad de confirmación. Asegúrese de que la implementación de MQTT de su cliente gestione correctamente los mensajes entrantes de QoS 0 y QoS 1.
