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, para enviar un mensaje a un dispositivo específico era necesario 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 el tema de destino. Cuandoconfirmation=true, AWS IoT Core entrega con QoS 1 y espera al PUBACK del receptor antes de devolver una respuesta correcta. Esto le proporciona un acuse de recibo de entrega de principio a fin. La respuesta de la API y Amazon CloudWatch Logs proporcionan una visibilidad completa del estado de la entrega y los motivos del error.
Rules no procesa los mensajes directos para la ejecución de AWS IoT las reglas, no se ponen en cola para dispositivos sin conexión y no admiten mensajes retenidos.
Requisitos previos
Tanto el remitente como el destinatario requieren políticas específicas para utilizar la mensajería directa. El remitente debe tener iot:SendDirectMessage permiso. El ID 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 detalles 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 datos del dispositivo y puntos finales de servicio para encontrar su punto final. -
client_ides el identificador único del cliente MQTT al que se va a enviar el mensaje. Los ID de cliente no deben superar los 128 caracteres y no pueden empezar con un signo de dólar ($). Los ID de cliente de MQTT deben estar codificados en URL (codificados en porcentaje) 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, consulte los límites y cuotas del corredor 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. Consulte la página de cuotas AWS IoT Core de servicio para conocer los límites de longitud y profundidad del tema. Para obtener más información, consulte los límites y cuotas del corredor de AWS IoT Core mensajes y del protocolo. -
confirmationes un booleano. Cuando se configura 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 correcta. Si la confirmación de entrega no se recibe dentro del período de espera especificado, la API devuelve el HTTP 504. -
timeoutes un número entero que representa el tiempo máximo, en segundos, que se tarda en 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, se ignora este parámetro. 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. Activa AWS IoT Core CloudWatch los registros para ver los registros de SendDirectMessage eventos detallados, incluido el campo de motivo de la gestión de errores programática.
| 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 confirmado la recepción 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 o los CloudWatch registros de respuesta HTTP para identificar un error específico y corregirlo. Asegúrese de que el nombre y el tema Client-id sean válidos y URL-encoded correctos. |
| 403: prohibido | Esto significa que la política del remitente no concede iot:SendDirectMessage nada al cliente ni al tema objetivo, o que la política del destinatario no concede iot:Receive concesiones al tema. Revise el mensaje o los CloudWatch registros de respuesta HTTP para identificar un error específico y actualice 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 o los CloudWatch registros de respuesta HTTP para ver 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», el cliente de destino tiene una sesión persistente que no ha caducado, pero actualmente está desconectado. |
| 4.1.3 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 publicación saliente. Revisa el mensaje o los CloudWatch registros de respuesta HTTP para ver 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 AWS Support con el TraceID que aparece en la respuesta. |
| 504: Tiempo de espera de Gateway | Esto significa que el receptor no envió PUBACK dentro del período de espera especificado. Aumente el valor del tiempo de espera, compruebe que el cliente MQTT del receptor envía PUBACK para los mensajes de QoS 1 o compruebe si el receptor procesa los mensajes lentamente. |
Ejemplos
Comportamiento del cliente receptor
Direct Messaging envía mensajes a los clientes (receptores) de MQTT sin necesidad de suscribirse a un tema. Para aprovechar al máximo la mensajería directa, el receptor debe admitir 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 receptor no se ha suscrito explícitamente. Sin embargo, algunas implementaciones de clientes de MQTT filtran o descartan los mensajes sobre temas a los que se ha dado de baja. Si su cliente descarta estos mensajes, la mensajería directa solo funcionará en los temas a los que el destinatario también esté suscrito. Para recibir mensajes directos sobre cualquier tema, compruebe que el gestor de mensajes de su cliente procese los mensajes independientemente del estado de la suscripción.
-
Gestionar 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. Cuandoconfirmation=true, el mensaje llega a QoS 1 y el cliente del receptor debe enviar un PUBACK para confirmar la entrega. Cuandoconfirmation=false, el mensaje llega a QoS 0 sin necesidad de acuse de recibo. Asegúrese de que la implementación de MQTT de su cliente gestione correctamente los mensajes entrantes de QoS 0 y QoS 1.
