MQTT

MQTT (Transporte de telemetría de colas de mensajes) es un protocolo de mensajería ligero y ampliamente adoptado que está diseñado para dispositivos restringidos. La compatibilidad de AWS IoT Core con MQTT se basa en la especificación MQTT v3.1.1 y en la especificación MQTT v5.0, con algunas diferencias, tal y como se documenta en AWS IoT diferencias con las especificaciones de MQTT. Al ser la última versión del estándar, MQTT 5 presenta varias características clave que hacen que un sistema basado en MQTT sea más robusto, incluidas nuevas mejoras de escalabilidad, informes de errores mejorados con respuestas de códigos de motivo, temporizadores de caducidad de mensajes, y sesiones y encabezados de mensajes de usuario personalizados. Para obtener más información sobre las funciones compatibles con MQTT 5, consulte Funciones AWS IoT Core compatibles con MQTT 5. AWS IoT Core también admite la comunicación entre versiones de MQTT (MQTT 3 y MQTT 5). Un editor de MQTT 3 puede enviar un mensaje de MQTT 3 a un suscriptor de MQTT 5 que recibirá un mensaje de publicación de MQTT 5, y viceversa.

AWS IoT Core admite conexiones de dispositivos que utilizan el protocolo MQTT y el protocolo MQTT sobre el protocolo WSS y que se identifican mediante un ID de cliente. AWS IoT Dispositivo SDKs es compatible con ambos protocolos y son las formas recomendadas de conectar los dispositivos a AWS IoT Core. El AWS IoT dispositivo SDKs admite las funciones necesarias para que los dispositivos y los clientes se conecten a los servicios y accedan AWS IoT a ellos. El dispositivo SDKs admite los protocolos de autenticación que requieren los AWS IoT servicios y los requisitos de identificación de conexión que requieren el protocolo MQTT y los protocolos MQTT sobre WSS. Para obtener información sobre cómo conectarse AWS IoT mediante el AWS dispositivo SDKs y enlaces a ejemplos AWS IoT en los idiomas compatibles, consulte. Conexión con MQTT mediante el dispositivo AWS IoT SDKs Para obtener más información acerca de los métodos de autenticación y las asignaciones de puertos para mensajes MQTT, consulte Protocolos, asignaciones de puertos y autenticación.

Si bien recomendamos usar el AWS IoT dispositivo SDKs para conectarse AWS IoT, no son obligatorios. Sin embargo SDKs, si no utiliza el AWS IoT Dispositivo, debe proporcionar la seguridad de conexión y comunicación necesaria. Los clientes también deben enviar la extensión TLS de Indicación de nombre de servidor (SNI) en la solicitud de conexión. Se rechazan los intentos de conexión que no incluyan la SNI. Para obtener más información, consulte Seguridad en el transporte en AWS IoT. Los clientes que utilizan usuarios y AWS credenciales de IAM para autenticar a los clientes deben proporcionar la autenticación correcta de la versión 4 de Signature.

Una vez que sus clientes estén conectados, puede supervisar y gestionar sus conexiones de clientes MQTT mediante. APIs Para obtener más información, consulte Gestión de las conexiones MQTT.

Conexión con MQTT mediante el dispositivo AWS IoT SDKs

Esta sección contiene enlaces al AWS IoT dispositivo SDKs y al código fuente de programas de muestra que ilustran cómo conectar un dispositivo al AWS IoT mismo. Las aplicaciones de muestra enlazadas aquí muestran cómo conectarse AWS IoT mediante el protocolo MQTT y MQTT a través de WSS.

Opciones de calidad de servicio (QoS) de MQTT

AWS IoT y el AWS IoT dispositivo SDKs admiten los niveles de calidad de servicio (QoS) 0 de MQTT y. 1 El protocolo MQTT define un tercer nivel de QoS, el 2 nivel, AWS IoT pero no lo admite. Solo el protocolo MQTT admite la característica QoS. HTTPS admite QoS al pasar un parámetro de cadena de consulta ?qos=qos donde el valor puede ser 0 o 1.

En esta tabla se describe cómo afecta cada nivel de QoS a los mensajes publicados en el agente de mensajes y por este.

Sesiones persistentes de MQTT

Las sesiones persistentes almacenan las suscripciones y los mensajes de un cliente, con una calidad de servicio (QoS) de 1, que el cliente no ha reconocido. Cuando el dispositivo se vuelve a conectar a una sesión persistente, la sesión se reanuda, las suscripciones se restablecen y los mensajes suscritos no confirmados recibidos y almacenados antes de la reconexión se envían al cliente.

El procesamiento de los mensajes almacenados se registra en CloudWatch métricas y registros. CloudWatch Para obtener información sobre las entradas escritas CloudWatch y los CloudWatch registros, consulte Métricas del agente de mensajes yEntrada de registro en cola.

Creación de una sesión persistente

En MQTT 3, puede crear una sesión persistente de MQTT enviando un mensaje CONNECT, que establezca la marca cleanSession en 0. Si no existe ninguna sesión para el cliente que envía el mensaje CONNECT, se crea una sesión persistente nueva. Si ya existe una sesión para el cliente, el cliente reanuda la sesión existente. Para crear una sesión limpia, se envía un mensaje CONNECT y se establece la marca cleanSession en 1, y el agente no almacenará ningún estado de la sesión cuando el cliente se desconecte.

En MQTT 5, las sesiones persistentes se gestionan configurando la marca Clean Start y Session Expiry Interval. Clean Start controla el inicio de la sesión de conexión y el final de la sesión anterior. Si se establece Clean Start = 1, se crea una nueva sesión y, si existe, se termina la sesión anterior. Si se establece Clean Start = 0, la sesión de conexión reanuda la sesión anterior, si ya existe. El intervalo de caducidad de la sesión controla el final de la sesión de conexión. El intervalo de caducidad de la sesión especifica el tiempo, en segundos (entero de 4 bytes), que durará una sesión tras la desconexión. La configuración Session Expiry interval = 0 hace que la sesión finalice inmediatamente después de la desconexión. Si el intervalo de caducidad de la sesión no se especifica en el mensaje CONNECT, el valor predeterminado es 0.

En MQTT 5, si establece Clean Start = 1 y Session Expiry Interval =0, equivale a una sesión limpia de MQTT 3. Si establece Clean Start = 0 y Session Expiry Interval >0, equivale a una sesión persistente de MQTT 3.

Operaciones durante una sesión persistente

Los clientes utilizan el atributo sessionPresent del mensaje de confirmación de conexión (CONNACK) para determinar si existe una sesión persistente. Si sessionPresent es 1, hay una sesión persistente y todos los mensajes almacenados para el cliente se envían al cliente después de que el cliente reciba el CONNACK, tal y como se describe en Tráfico de mensajes tras la reconexión a una sesión persistente. Si sessionPresent es 1, el cliente no necesita volver a suscribirse. Sin embargo, si sessionPresent está establecido en 0, significa que no existe ninguna sesión persistente y que el cliente debe volver a suscribirse a sus filtros de temas.

Una vez que el cliente se une a una sesión persistente, puede publicar mensajes y suscribirse a filtros de temas sin ningún indicador adicional en cada operación.

Tráfico de mensajes tras volver a conectarse a una sesión persistente

Una sesión persistente representa una conexión en curso entre un cliente y un agente de mensajes de MQTT. Cuando un cliente se conecta al agente de mensajes mediante una sesión persistente, el agente de mensajes guarda todas las suscripciones que el cliente realiza durante la conexión. Cuando el cliente se desconecta, el agente de mensajes almacena los mensajes QoS 1 sin confirmar y los mensajes QoS 1 nuevos publicados en los temas a los que el cliente está suscrito. Los mensajes se almacenan según el límite de la cuenta. Mensajes que superen el límite se eliminarán. Para más información acerca de los límites de mensajes persistentes, consulte Puntos de conexión y cuotas de AWS IoT Core. Cuando el cliente vuelve a conectarse la sesión persistente, todas las suscripciones se restablecen y todos los mensajes almacenados se envían al cliente a una velocidad máxima de 10 mensajes por segundo. En MQTT 5, si un QoS 1 saliente con el intervalo de caducidad del mensaje caduca cuando un cliente está desconectado, una vez que se reanude la conexión, el cliente no recibirá el mensaje caducado.

Tras la reconexión, los mensajes almacenados se envían al cliente a una velocidad limitada a 10 mensajes almacenados por segundo, junto con el tráfico de mensajes actual hasta que se alcance el límite de Publish requests per second per connection. Como la velocidad de entrega de los mensajes almacenados es limitada, se tardarán varios segundos en entregar todos los mensajes almacenados si una sesión tiene más de 10 mensajes almacenados que entregar después de la reconexión.

En el caso de los suscriptores compartidos, los mensajes se pondrán en cola si al menos un suscriptor de un grupo utiliza una sesión persistente y ningún suscriptor está conectado para recibir el mensaje de QoS 1. La eliminación de la cola de mensajes se realiza a una velocidad máxima de 20 mensajes por segundo por cada suscriptor activo de un grupo. Para obtener más información, consulta la sección sobre la cola de mensajes de suscripciones compartidas.

Finalizar una sesión persistente

Las sesiones persistentes pueden finalizar de una de las siguientes formas:

En MQTT 3, el valor predeterminado del tiempo de caducidad de las sesiones persistentes es de una hora, y esto se aplica a todas las sesiones de la cuenta.

En MQTT 5, puede establecer el intervalo de caducidad de la sesión para cada sesión en los paquetes CONNECT y DISCONNECT.

Para el intervalo de caducidad de la sesión en el paquete DISCONNECT:

Reconexión después de que haya caducado una sesión persistente

Si un cliente no se vuelve a conectar a su sesión persistente antes de que caduque, la sesión finaliza y los mensajes almacenados se descartan. Cuando un cliente se vuelve a conectar después de que la sesión haya caducado con una marca cleanSession establecida en 0, el servicio crea una nueva sesión persistente. Las suscripciones o los mensajes de la sesión anterior no están disponibles para esta sesión porque se descartaron al expirar la sesión anterior.

Cargos por mensajes de sesión persistentes

Los mensajes se cobran Cuenta de AWS cuando el agente de mensajes envía un mensaje a un cliente o a una sesión persistente fuera de línea. Cuando un dispositivo desconectado con una sesión persistente se vuelve a conectar y reanuda la sesión, los mensajes almacenados se envían al dispositivo y se vuelven a cargar a su cuenta. Para obtener más información sobre los precios de los mensajes, consulte los Precios de AWS IoT Core : Mensajería.

El tiempo de caducidad predeterminado de la sesión persistente, de una hora, se puede aumentar mediante el proceso de aumento de límites estándar. Tenga en cuenta que aumentar el tiempo de caducidad de la sesión puede aumentar los cargos por mensajes, ya que el tiempo adicional podría permitir almacenar más mensajes para el dispositivo sin conexión y esos mensajes adicionales se cargarían en su cuenta según la tarifa de mensajería estándar. El tiempo de caducidad de la sesión es aproximado y una sesión puede prolongarse hasta 30 minutos más que el límite de la cuenta; sin embargo, una sesión no superará el límite de la cuenta. Para obtener más información acerca de los límites de sesión, consulte Cuotas de servicio de AWS.

Mensajes retenidos de MQTT

AWS IoT Core admite el RETAIN indicador descrito en el protocolo MQTT. Cuando un cliente establece la RETAIN marca en un mensaje MQTT que publica, AWS IoT Core guarda el mensaje. A continuación, puede enviarse a los nuevos suscriptores, recuperarse mediante una llamada a la operación GetRetainedMessage y visualizarse en la consola de AWS IoT.

Las tareas habituales con mensajes MQTT retenidos en AWS IoT Core

AWS IoT Core guarda los mensajes MQTT con la RETAIN bandera puesta. Estos mensajes retenidos se envían a todos los clientes que se han suscrito al tema, como un mensaje MQTT normal, y también se almacenan para enviarlos a los nuevos suscriptores del tema.

Los mensajes MQTT retenidos requieren políticas específicas para autorizar a los clientes a acceder a ellos. Para ver ejemplos del uso de políticas de mensajes retenidos, consulte Ejemplos de políticas de mensajes retenidos.

En esta sección se describen las operaciones comunes que implican los mensajes retenidos.

Facturación y mensajes retenidos

La publicación de mensajes con la RETAIN marca marcada desde un cliente, mediante una AWS IoT consola o mediante una llamada Publishconlleva los gastos de mensajería adicionales descritos en AWS IoT Core la sección de precios (Mensajes).

La recuperación de los mensajes retenidos por parte de un cliente, mediante una AWS IoT consola o mediante una llamada GetRetainedMessageconlleva gastos de mensajería además de los cargos por uso normal de la API. Los cargos adicionales se describen en Precios de mensajería de AWS IoT Core.

Los mensajes Will que se publiquen cuando un dispositivo se desconecte inesperadamente incurrirán en los cargos de mensajería descritos en el apartado Precios de mensajería de AWS IoT Core.

Para obtener más información sobre los costes de mensajería, consulte Precios de mensajería de AWS IoT Core.

Comparación de los mensajes retenidos de MQTT y las sesiones persistentes de MQTT

Los mensajes retenidos y las sesiones persistentes son características estándar de MQTT que permiten a los dispositivos recibir los mensajes que se publicaron sin conexión a Internet. Los mensajes retenidos se pueden publicar desde sesiones persistentes. En esta sección se describen los aspectos clave de estas características y la forma en que funcionan juntas.

Para obtener más información acerca del almacenamiento persistente, consulte Sesiones persistentes de MQTT.

Con mensajes retenidos, el cliente de publicación determina si un mensaje debe conservarse y entregarse a un dispositivo después de que se conecte, independientemente de que haya tenido una sesión anterior o no. La elección de almacenar un mensaje la realiza el editor y el mensaje almacenado se entrega a todos los clientes actuales y futuros que se suscriban a suscripciones QoS 0 o QoS 1. Los mensajes retenidos guardan solo un mensaje sobre un tema determinado cada vez.

Cuando una cuenta ha almacenado el número máximo de mensajes retenidos, AWS IoT Core devuelve una respuesta limitada a los mensajes publicados con la marca RETAIN activada y con cargas útiles superiores a 0 bytes hasta que se eliminen algunos mensajes retenidos y el recuento de mensajes retenidos caiga por debajo del límite.

MQTT retuvo los mensajes y Device Shadows AWS IoT

Tanto los mensajes retenidos como las sombras de dispositivo retienen los datos de un dispositivo, pero se comportan de manera diferente y tienen diferentes propósitos. En esta sección se describen sus similitudes y diferencias.

Mensajes Last Will and Testament (LWT) de MQTT

Last Will and Testament (LWT) es una característica de MQTT. Con LWT, los clientes pueden especificar un mensaje que el agente publicará en un tema definido por el cliente y lo enviará a todos los clientes que se hayan suscrito al tema cuando se produzca una desconexión no iniciada. El mensaje que especifican los clientes se denomina mensaje LWT o mensaje Will, y el tema que definen los clientes se denomina tema Will. Puede especificar un mensaje LWT cuando un dispositivo se conecte al agente. Estos mensajes se pueden conservar configurando la marca Will Retain en el campo Connect Flag bits durante la conexión. Por ejemplo, si la marca Will Retain está establecido en 1, el mensaje Will se almacenará en el agente en el tema Will asociado. Para obtener más información, consulte Plantillas de mensaje.

Al administrar las conexiones de los clientes, puede controlar si los mensajes de LWT se publican al desconectar un cliente. Para obtener más información, consulte Gestión de las conexiones MQTT.

El agente almacenará los mensajes Will hasta que se produzca una desconexión no iniciada. Cuando eso suceda, el agente publicará los mensajes para todos los clientes que se hayan suscrito al tema Will para notificarles la desconexión. Si el cliente se desconecta del agente con una desconexión iniciada por el cliente mediante el mensaje MQTT DISCONNECT, el agente no publicará los mensajes LWT almacenados. En el resto de los casos, se enviarán los mensajes de LWT. Para obtener una lista completa de los escenarios de desconexión en los que el agente enviará los mensajes de LWT, consulte Eventos de conexión y desconexión.

Uso de connectAttributes

ConnectAttributes le permite especificar qué atributos quiere usar en su mensaje de conexión en sus políticas de IAM, como PersistentConnect y LastWill. Con ConnectAttributes, puede crear políticas que no otorguen a los dispositivos acceso a nuevas características de forma predeterminada, lo que puede resultar útil si un dispositivo se ve comprometido.

connectAttributes admite las siguientes características:

De forma predeterminada, su política tiene una conexión no persistente y no se transfieren atributos para esta conexión. Debe especificar una conexión persistente en su política de IAM si desea tener una.

Al administrar las conexiones de los clientes, puede ver los atributos de conexión y la configuración de sesión de los clientes conectados. Para obtener más información, consulte Gestión de las conexiones MQTT.

Para ver ejemplos de ConnectAttributes, consulte Ejemplos de políticas de conexión.

Características compatibles con MQTT 5

AWS IoT Core La compatibilidad con MQTT 5 se basa en la especificación MQTT v5.0, con algunas diferencias, tal y como se describe en. AWS IoT diferencias con las especificaciones de MQTT

Suscripciones compartidas

AWS IoT Core admite suscripciones compartidas tanto para MQTT 3.1.1 como para MQTT 5. Las suscripciones compartidas permiten que varios clientes compartan una suscripción a un tema y solo un cliente recibirá los mensajes publicados sobre ese tema mediante una distribución aleatoria. Las suscripciones compartidas pueden equilibrar eficazmente la carga de los mensajes MQTT entre varios suscriptores. Por ejemplo, supongamos que tiene 1000 dispositivos que publican sobre el mismo tema y 10 aplicaciones de segundo plano que procesan esos mensajes. En ese caso, las aplicaciones secundarias pueden suscribirse al mismo tema y cada una de ellas recibiría aleatoriamente los mensajes publicados por los dispositivos sobre el tema compartido. De hecho, se trata de “compartir” la carga de esos mensajes. Las suscripciones compartidas también permiten una mayor resiliencia. Cuando una aplicación de segundo plano se desconecta, el agente distribuye la carga entre los suscriptores restantes del grupo. Cuando todos los suscriptores se desconectan, los mensajes se ponen en cola.

Las funciones de cola de mensajes están disponibles para las suscripciones compartidas en las conexiones MQTT 3.1.1 y MQTT 5 a fin de mejorar la fiabilidad de la entrega de mensajes.

Para utilizar las suscripciones compartidas, los clientes se suscriben al filtro de temas de una suscripción compartida de la siguiente manera:

$share/{ShareName}/{TopicFilter}

Las suscripciones que tienen el mismo contenido {ShareName}/{TopicFilter} pertenecen al mismo grupo de suscripciones compartidas. Puede crear varios grupos de suscripciones compartidas y no superar el límite de suscripciones compartidas por grupo. Para obtener más información, consulte Puntos de conexión y cuotas de AWS IoT Core en la Referencia general de AWS .

En las siguientes tablas se comparan las suscripciones no compartidas y las suscripciones compartidas:

sports/tennis
sports/#

$share/consumer/sports/tennis
$share/consumer/sports/#

Flujo de suscripciones no compartidas	Flujo de suscripciones compartidas

Notas importantes sobre el uso de suscripciones compartidas

Para obtener más información sobre los límites de las suscripciones compartidas, consulte los AWS IoT Core puntos finales y las cuotas en la Referencia AWS general. Para probar las suscripciones compartidas mediante el cliente AWS IoT MQTT de la AWS IoT consola, consulte. Probar las suscripciones compartidas en el cliente MQTT También puede ver a qué temas están suscritos los clientes conectados, incluidas las suscripciones compartidas, mediante las funciones de administración de conexiones de los clientes. Para obtener más información, consulte Gestión de las conexiones MQTT. Para obtener más información sobre las suscripciones compartidas, consulte Suscripciones compartidas de la MQTTv5 especificación 2.0.

Suscripciones compartidas (cola de mensajes)

Para mejorar la fiabilidad de la entrega de mensajes, las suscripciones compartidas incluyen funciones de cola de mensajes que almacenan los mensajes cuando no hay suscriptores en línea disponibles. Cuando un grupo de suscripciones compartidas contiene al menos un miembro con una sesión persistente, la función de cola está habilitada para el grupo. Al distribuir los mensajes, los miembros en línea se seleccionan como destinatarios. Los mensajes de QoS 1 se ponen en cola cuando no se encuentra ningún miembro en línea o cuando los suscriptores superan el límite. Publish requests per second per connection Los mensajes en cola se entregan cuando los miembros existentes reanudan sus sesiones persistentes o cuando los miembros nuevos se unen al grupo. Los mensajes en cola se envían a una velocidad máxima de 20 mensajes por segundo por cada suscriptor activo del grupo, junto con cualquier otro mensaje que se entregue al suscriptor según las suscripciones.

De forma predeterminada, la retención de mensajes en cola sigue la cuota. Persistent Session expiry period Sin embargo, si se establece un intervalo de caducidad de mensajes (MEI) en el mensaje de publicación entrante, el MEI tiene prioridad. Cuando el MEI está presente, determina el período de retención del mensaje, independientemente del período de caducidad de la sesión persistente.

Las tasas de cola de mensajes están limitadas en función de la Queued messages per second per accountcuota y la cantidad de mensajes está limitada por la Maximum number of queued messages per shared subscription groupcuota.

Cuando se superan estos límites, solo se conservan los mensajes que ya estaban en cola antes de alcanzar el límite. Se eliminan los nuevos mensajes entrantes que superen los límites. El sistema no reemplaza los mensajes antiguos en cola por otros más nuevos.

La cola de mensajes se registra en CloudWatch las métricas y CloudWatch los registros. Para obtener información sobre las entradas escritas CloudWatch y los CloudWatch registros, consulte Métricas del agente de mensajes yEntrada de registro en cola. Los mensajes en cola se siguen facturando a la tarifa de mensajería estándar. Para obtener más información sobre los precios de los mensajes, consulte Precios de AWS IoT Core.

Ciclo de vida de la sesión en un grupo de suscripciones compartidas

Cuando una sesión limpia se suscribe a un grupo, se convierte en miembro en línea del grupo. Cuando se cancela la suscripción o se desconecta, la sesión limpia abandona el grupo.

Cuando una sesión persistente se suscribe a un grupo, pasa a ser miembro en línea del grupo. Cuando se desconecta, permanece en el grupo, pero pasa a ser miembro del grupo sin conexión. Cuando se vuelve a conectar, vuelve a ser miembro en línea. La sesión persistente abandona el grupo cuando se da de baja de forma explícita o cuando caduca tras la desconexión.

Inicio limpio y caducidad de la sesión

Puede usar las funciones de inicio limpio y caducidad de la sesión para gestionar sus sesiones persistentes con más flexibilidad. Un marca de inicio limpio indica si la sesión debe iniciarse sin utilizar una sesión existente. Un intervalo de caducidad de la sesión indica cuánto tiempo se debe conservar la sesión tras una desconexión. El intervalo de caducidad de la sesión se puede modificar al desconectarse. Para obtener más información, consulte Sesiones persistentes de MQTT.

Código de motivo en todas ACKs

Puede depurar o procesar los mensajes de error más fácilmente utilizando los códigos de motivo. El agente de mensajes devuelve los códigos de motivo en función del tipo de interacción con el agente (suscribirse, publicar o confirmar). Para obtener más información, consulte Códigos de motivo de MQTT. Para obtener una lista completa de los códigos de motivo de MQTT, consulte la especificación de MQTT v5.

Alias de temas

Puede sustituir el nombre de un tema por un alias de tema, que es un entero de dos bytes. El uso de alias de temas puede optimizar la transmisión de los nombres de los temas y reducir potencialmente los costos de datos en los servicios de datos medidos. AWS IoT Core tiene un límite predeterminado de 8 alias de temas. Para obtener más información, consulte Puntos de conexión y cuotas de AWS IoT Core en la Referencia general de AWS .

Caducidad de los mensajes

Puede agregar valores de caducidad de los mensajes a los mensajes publicados. Estos valores representan el intervalo de caducidad del mensaje (MEI) en segundos. Si los mensajes no se envían a los suscriptores en ese intervalo, los mensajes caducan y se eliminan. Si no establece el valor de caducidad del mensaje, el mensaje no caducará.

Al salir, el suscriptor recibirá un mensaje con el tiempo restante del intervalo de caducidad. Por ejemplo, si un mensaje de publicación entrante tiene una caducidad de 30 segundos y se envía al suscriptor después de 20 segundos, el campo de caducidad del mensaje se actualizará a 10. Es posible que el mensaje recibido por el suscriptor tenga un MEI actualizado de 0. Esto se debe a que tan pronto como el tiempo restante sea de 999 ms o menos, se actualizará a 0.

En AWS IoT Core, el MEI mínimo es 1. Si el intervalo se establece en 0 desde el lado del cliente, se ajustará a 1. El intervalo máximo de caducidad de mensajes es 604800 (7 días). Cualquier valor superior a este valor se ajustará al valor máximo.

En la comunicación entre versiones, el comportamiento de caducidad del mensaje lo decide la versión MQTT del mensaje de publicación entrante. Por ejemplo, un mensaje con fecha de caducidad enviado por una sesión a través de la cual se ha conectado MQTT5 puede caducar en el caso de los dispositivos suscritos con MQTT3 sesiones. En la siguiente tabla se muestra cómo la caducidad de los mensajes admite los siguientes tipos de mensajes de publicación:

Otras características de MQTT 5

Desconexión del servidor

Cuando se produce una desconexión, el servidor puede enviar de forma proactiva al cliente una desconexión para notificar el cierre de la conexión con un código de motivo de la desconexión.

Solicitud/respuesta

Los editores pueden solicitar que el destinatario envíe una respuesta a un tema especificado por el editor en el momento de la recepción.

Tamaño máximo de paquete

El cliente y el servidor pueden especificar de forma independiente el tamaño máximo de paquete que admiten.

Formato de carga y tipo de contenido

Puede especificar el formato de carga (binario, texto) y el tipo de contenido al publicar un mensaje. Se reenvían al destinatario del mensaje.

Propiedades de MQTT 5

Las propiedades de MQTT 5 son adiciones importantes al estándar MQTT para admitir las nuevas funciones de MQTT 5, como la caducidad de sesión y el patrón. Request/Response En AWS IoT Core, puede crear reglas que reenvíen las propiedades de los mensajes salientes o utilizar HTTP Publish para publicar los mensajes MQTT con algunas de las nuevas propiedades.

En la siguiente tabla se enumeran todas las propiedades de MQTT 5 compatibles. AWS IoT Core

Códigos de motivo de MQTT

MQTT 5 introduce una mejora en la notificación de errores con respuestas en códigos de motivo. AWS IoT Core puede devolver códigos de motivo, incluidos, entre otros, los siguientes agrupados por paquetes. Para obtener una lista completa de los códigos de motivo compatibles con MQTT 5, consulte las especificaciones de MQTT 5.

AWS IoT diferencias con las especificaciones de MQTT

La implementación del agente de mensajes se basa en la especificación MQTT v3.1.1 y la especificación MQTT v5.0, pero se diferencia de las especificaciones en los siguientes aspectos:

Gestión de las conexiones MQTT

AWS IoT Core proporciona ayuda APIs para gestionar las conexiones MQTT, incluida la posibilidad de desconectar los clientes y gestionar sus sesiones. Estas funciones le proporcionan un mayor control sobre su flota de AWS IoT clientes y le ayudan a solucionar problemas de conexión.

DeleteConnection API

Utilice la DeleteConnection API para desconectar los dispositivos MQTT AWS IoT Core especificando su cliente IDs. Al desconectar un cliente, lo AWS IoT Core desconecta del intermediario de mensajes y, si lo desea, puede limpiar el estado de la sesión y suprimir el AWS IoT Core mensaje de Last Will and Testament (LWT).

Cuando llamas a la DeleteConnection API, AWS IoT Core realiza varias acciones para garantizar una desconexión limpia. AWS IoT Core primero envía un mensaje de desconexión de MQTT al cliente para finalizar la sesión de MQTT. A continuación, el servicio cierra el conector subyacente TCP/TLS .

El agente de mensajes envía un DISCONNECT paquete al dispositivo y publica un evento del ciclo de vida con el motivo de la desconexiónAPI_INITIATED_DISCONNECT. Esto le ayuda a identificar cuándo se inició una desconexión a través de la API y no por el cliente o si se debió a problemas de red. Puede supervisar estos eventos con fines de visibilidad, resolución de problemas y auditoría. Por ejemplo, puede usar AWS IoT reglas para procesar estos eventos y realizar un seguimiento de cuándo y por qué se desconectaron los clientes.

Si establece el cleanSession parámetro entrue, AWS IoT Core elimina el estado de la sesión del cliente, incluidas todas las suscripciones y los mensajes en cola. Si limpia una sesión, la sesión persistente finaliza. Si el cliente era una sesión persistente y el preventWillMessage parámetro está establecido enfalse, el servicio envía el mensaje LWT si está disponible, lo que resulta útil durante las operaciones de mantenimiento planificadas.

Cuando llamas a la DeleteConnection API, el proceso de desconexión comienza inmediatamente, pero el momento exacto en que el cliente reconoce la desconexión puede variar en función de las condiciones de la red y de la implementación del cliente. La mayoría de los clientes detectarán la desconexión en unos segundos, pero en algunos casos con una conectividad de red deficiente, es posible que el cliente tarde más en reconocer que se ha desconectado.

Para obtener información sobre precios, consulte Precios de AWS IoT Core.

Casos de uso

La DeleteConnection API es útil para gestionar los clientes que se comportan mal y que muestran un comportamiento problemático o consumen recursos excesivos. Al forzar la desconexión, puede asegurarse de que los clientes restablezcan sus conexiones con la autenticación y la autorización adecuadas, lo que puede ayudar a resolver los problemas de consumo de recursos.

Los escenarios de redireccionamiento de clientes también se benefician de esta API. Cuando necesite redirigir a los clientes a distintos puntos de conexión o bien Regiones de AWS, puede desconectarlos mediante programación y hacer que se vuelvan a conectar a un AWS IoT Core punto final diferente cambiando la configuración de DNS. Esta API puede ayudar a resolver conexiones bloqueadas o eliminar estados de sesión problemáticos que podrían estar impidiendo el funcionamiento normal.

Parámetros de la API

La DeleteConnection API acepta los siguientes parámetros:

Sintaxis de la API

La DeleteConnection API utiliza el siguiente formato de solicitud HTTP:

DELETE /connections/<clientId>?cleanSession=<cleanSession>&preventWillMessage=<preventWillMessage> HTTP/1.1

Ejemplos de solicitudes:

// Basic disconnect (preserves session, allows LWT message)
DELETE /connections/myDevice123 HTTP/1.1

// Disconnect and clear session
DELETE /connections/myDevice123?cleanSession=TRUE HTTP/1.1

// Disconnect, clear session, and prevent LWT message
DELETE /connections/myDevice123?cleanSession=TRUE&preventWillMessage=TRUE HTTP/1.1

Las solicitudes correctas devuelven HTTP 200 OK sin cuerpo de respuesta.

Permisos necesarios

Para usar la DeleteConnection API, necesitas el siguiente permiso de IAM:

iot:DeleteConnection

Puede conceder este permiso a un cliente específico IDs mediante políticas basadas en recursos. Por ejemplo:

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Action": "iot:DeleteConnection",
            "Resource": "arn:aws:iot:region:account:client/myDevice*"
        }
    ]
}

Consideraciones importantes

Los clientes desconectados pueden intentar volver a conectarse inmediatamente, a menos que haya implementado una lógica adicional para impedir la reconexión. La operación de desconexión solo termina la conexión actual y no impide que una conexión se vuelva a conectar. Si necesitas impedir la reconexión, considera implementar una lógica del lado del cliente o deshabilitar la credencial de un dispositivo.

Los límites de velocidad se aplican a la API como parte de la limitación de velocidad de la API estándar. AWS IoT Core Cuando planifique las operaciones de desconexión masiva, asegúrese de tener en cuenta estos límites e implementar la lógica de reintentos y las estrategias de procesamiento por lotes adecuadas para evitar las limitaciones. Para obtener más información, consulte Puntos de conexión y cuotas de AWS IoT Core.

Respuestas de error

La DeleteConnection API puede devolver las siguientes respuestas de error: