Compartir vía

Características de MQTT compatibles con la característica de agente MQTT de Azure Event Grid

  • Artículo

MQTT es un protocolo de transporte de mensajería de publicación y suscripción diseñado para entornos restringidos. Es eficaz, escalable y confiable, lo que lo convierte en el estándar de excelencia para la comunicación en escenarios de IoT. MQTT broker admite clientes que publican y se suscriben a mensajes mediante MQTT v3.1.1, MQTT v3.1.1 a través de WebSockets, MQTT v5 y MQTT v5 a través de WebSockets. MQTT broker también admite la comunicación entre versiones de MQTT (MQTT 3.1.1 y MQTT 5).

MQTT v5 ha introducido muchas mejoras con respecto a MQTT v3.1.1 para ofrecer una comunicación más fluida, transparente y eficaz. Se han agregado:

  • Mejor informe de errores.
  • Clientes de comunicación más transparentes gracias a características como propiedades de usuario y tipo de contenido.
  • Más control para los clientes sobre la comunicación gracias a características como la expiración de mensajes y sesiones.
  • Patrones importantes estándar, como el patrón de solicitud-respuesta.

Flujo de conexión:

Los clientes MQTT deben conectarse a través de TLS 1.2 o TLS 1.3. Si intenta omitir este paso, se producirá un error en la conexión.

Al conectarse a MQTT broker, use los siguientes puertos durante la comunicación a través de MQTT:

  • MQTT v3.1.1 y MQTT v5 en el puerto TCP 8883
  • MQTT v3.1.1 a través de WebSocket y MQTTv5 a través de WebSocket en el puerto TCP 443.

El paquete CONNECT debe incluir las siguientes propiedades:

  • El campo ClientId es obligatorio y debe incluir el nombre de sesión del cliente. El nombre de la sesión debe ser único en el espacio de nombres. Puede usar el nombre de autenticación de cliente como nombre de sesión si cada cliente usa una sesión por cliente. Si un cliente usa varias sesiones, debe usar valores diferentes para ClientId para cada una de sus sesiones.
  • El campo de nombre de usuario es necesario si no seleccionó un valor en alternativeAuthenticationNameSources durante la creación del espacio de nombres. En ese caso, debe proporcionar el nombre de autenticación del cliente en el campo de nombre de usuario. Ese nombre debe coincidir con el nombre de autenticación proporcionado y el valor en el campo de certificado del cliente que se especificó durante la creación del recurso de cliente.

Obtén más información sobre la autenticación de cliente.

Compatibilidad con varias sesiones

La compatibilidad con varias sesiones permite a los clientes MQTT de la aplicación tener una implementación más escalable y confiable mediante la conexión a MQTT broker con varias sesiones activas al mismo tiempo.

Configuración del espacio de nombres

Antes de usar esta característica, debe configurar el espacio de nombres para permitir varias sesiones por cliente. Siga estos pasos para configurar varias sesiones por cliente en Azure Portal:

  • En Azure Portal, vaya a su espacio de nombres.
  • En Configuración, cambie el valor de Número máximo de sesiones de cliente por nombre de autenticación al número deseado de sesiones por cliente.
  • Seleccione Aplicar.

Nota

Para la configuración de la CLI de Azure, actualice la propiedad MaxClientSessionsPerAuthenticationName en la carga del espacio de nombres con el valor deseado.

Flujo de conexión:

Los paquetes CONNECT para cada sesión deben incluir las siguientes propiedades:

  • Proporcione la propiedad Username en el paquete CONNECT para indicar el nombre de autenticación del cliente.
  • Proporcione la propiedad ClientID en el paquete CONNECT para indicar el nombre de sesión, como que haya uno o más valores para ClientID por cada nombre de usuario.

Por ejemplo, las siguientes combinaciones de Username y ClientId en el paquete CONNECT permiten que el cliente "Mgmt-application" se conecte a MQTT broker en tres sesiones independientes:

  • Primera sesión:
    • Nombre de usuario: Mgmt-application
    • ClientId: Mgmt-Session1
  • Segunda sesión:
    • Nombre de usuario: Mgmt-application
    • ClientId: Mgmt-Session2
  • Tercera sesión:
    • Nombre de usuario: Mgmt-application
    • ClientId: Mgmt-Session3

Diagrama de un ejemplo de varias sesiones.

Para obtener más información, consulta Procedimientos a fin de establecer varias sesiones para un solo cliente.

Control de sesiones:

  • Si un cliente intenta asumir la sesión activa de otro cliente mediante la presentación de su nombre de sesión con un nombre de autenticación diferente, su solicitud de conexión será rechazada con un error no autorizado. Por ejemplo, si el cliente B intenta conectarse a la sesión 123 que se asigna en ese momento al cliente A, se rechaza la solicitud de conexión del cliente B. Dicho esto, si el mismo cliente intenta volver a conectarse con los mismos nombres de sesión y el mismo nombre de autenticación, puede asumir su sesión existente.
  • Si se elimina un recurso de cliente sin finalizar su sesión, ningún otro cliente podrá usar su nombre de sesión hasta que expire la sesión. Por ejemplo, si el cliente B crea una sesión con el nombre de sesión 123, el cliente B se elimina, el cliente A no se puede conectar a la sesión 123 hasta que expire.
  • El límite del número de sesiones por cliente se aplica a las sesiones en línea y sin conexión en cualquier momento dado. Por ejemplo, considere un espacio de nombres con el número máximo de sesiones de cliente por nombre de autenticación establecido en 1. Si el cliente A se conecta con una sesión persistente 123 y, a continuación, se desconecta, el cliente A no podrá conectarse con una nueva sesión 456, ya que su sesión 123 sigue activa aunque esté sin conexión. En consecuencia, se recomienda que el mismo cliente siempre se vuelva a conectar con los mismos nombres de sesión estáticos en lugar de generar un nuevo nombre de sesión con cada reconexión.

Características de MQTT

La característica de agente MQTT de Azure Event Grid es compatible con las siguientes características de MQTT:

Calidad del servicio (QoS)

MQTT broker admite QoS 0 y 1, que definen la garantía de entrega de mensajes en paquetes PUBLISH y SUBSCRIBE entre clientes y MQTT broker. QoS 0 garantiza la entrega como máximo una vez, el suscriptor no confirma los mensajes con QoS 0 ni el publicador los retransmite. QoS 1 garantiza la entrega al menos una vez, el suscriptor confirma los mensajes y el publicador los retransmite si no se confirman. QoS permite a los clientes controlar la eficiencia y confiabilidad de la comunicación.

Sesiones persistentes

MQTT broker admite sesiones persistentes para MQTT v3.1.1 de forma que MQTT broker conserva información sobre la sesión de un cliente en caso de desconexiones para garantizar la confiabilidad de la comunicación. Esta información incluye las suscripciones del cliente y los mensajes QoS 1 que faltan o que no se han confirmado. Los clientes pueden configurar una sesión persistente estableciendo la marca cleanSession en el paquete CONNECT en false.

Inicio limpio y expiración de la sesión

MQTT v5 ha introducido las características de inicio limpio y expiración de sesión como una mejora respecto a MQTT v3.1.1 en el control de la persistencia de la sesión. El inicio limpio es una característica que permite a un cliente iniciar una nueva sesión con MQTT broker, descartando los datos de sesión anteriores. La expiración de sesión permite a un cliente informar a MQTT broker cuando se considera que una sesión inactiva ha expirado y se quita automáticamente. En el paquete CONNECT, un cliente puede establecer la marca Clean Start en True o intervalo de expiración de sesión corta por motivos de seguridad o para evitar posibles conflictos de datos que puedan haberse producido durante la sesión anterior. Un cliente también puede establecer un inicio limpio en false o un intervalo de expiración de sesión largo para garantizar la confiabilidad y eficacia de las sesiones persistentes.

Configuración del intervalo máximo de expiración de la sesión

Puede configurar el intervalo máximo de expiración de la sesión permitido para todos los clientes que se conectan al espacio de nombres de Event Grid. En el caso de los clientes MQTT v3.1.1, el límite configurado se aplica como el intervalo de expiración predeterminado de sesión para todas las sesiones persistentes. En el caso de los clientes MQTT v5, el límite configurado se aplica como valor máximo para la propiedad Intervalo de expiración de sesión en el paquete CONNECT y cualquier valor que supere el límite se ajusta. El valor predeterminado de esta propiedad de espacio de nombres es de 1 hora y se puede extender hasta 8 horas. Siga estos pasos para configurar el intervalo máximo de expiración de la sesión en Azure Portal:

  • En Azure Portal, vaya a su espacio de nombres.
  • En Configuración, cambie el valor del Intervalo de expiración máximo de la sesión en horas al límite deseado.
  • Seleccione Aplicar.

Captura de pantalla de la configuración del intervalo de expiración máximo de la sesión.

Desbordamiento de sesión

MQTT broker mantiene una cola de mensajes para cada sesión de MQTT activa que no está conectada, hasta que el cliente se conecte de nuevo con MQTT broker para recibir los mensajes de la cola. Si un cliente no se conecta para recibir los mensajes QOS1 en cola, la cola de sesión comienza a acumular los mensajes hasta que alcanza su límite: 100 mensajes o 1 MB. Una vez que la cola alcanza su límite durante la duración de la sesión, la sesión finaliza.

Mensajes de Última voluntad y testamento (LWT)

Última voluntad y Testamento (LWT) notifica a sus clientes MQTT las desconexiones bruscas de otros clientes MQTT. Puedes usar LWT a fin de garantizar un flujo predecible y fiable de comunicación entre los clientes MQTT durante las desconexiones inesperadas, lo que resulta útil para escenarios en los que la comunicación en tiempo real, la fiabilidad del sistema y las acciones coordinadas son críticas. Los clientes que colaboran para realizar tareas complejas pueden reaccionar ante los mensajes LWT entre sí ajustando su comportamiento, redistribuyendo tareas o tomando el control de ciertas responsabilidades para mantener el rendimiento y la estabilidad del sistema. Para usar LWT, un cliente puede especificar el mensaje will, el tema will y el resto de las propiedades de will en el paquete CONNECT durante la conexión. Cuando el cliente se desconecta bruscamente, MQTT broker publica el mensaje en todos los clientes que se suscriben al tema will. Para reducir el ruido de desconexiones fluctuantes, el cliente puede establecer el intervalo de retraso en un valor superior a cero. En ese caso, si el cliente se desconecta abruptamente pero restaura la conexión antes de que expire el intervalo de retraso, el mensaje no se publicará.

Propiedades de usuario

MqTT broker admite propiedades de usuario en paquetes PUBLISH de MQTT v5 que permiten agregar pares clave-valor personalizados en el encabezado del mensaje para proporcionar más contexto sobre el mensaje. Los casos de uso de las propiedades de usuario son versátiles. Puede usar esta característica para incluir el propósito o el origen del mensaje para que el receptor pueda controlar el mensaje sin analizar la carga, lo que ahorra recursos informáticos. Por ejemplo, un mensaje con una propiedad de usuario que indica su propósito como "advertencia" podría desencadenar una lógica de control diferente a una con el propósito de "información".

Patrón de solicitud-respuesta

MQTTv5 introdujo campos en el encabezado del paquete PUBLISH de MQTT que proporcionan contexto para el mensaje de respuesta en el patrón de solicitud-respuesta. Estos campos incluyen un tema de respuesta y un identificador de correlación que el respondedor puede usar en la respuesta sin configuración previa. La información de respuesta permite una comunicación más eficaz para el patrón de solicitud-respuesta estándar que se usa en escenarios de comando y control.

Diagrama del ejemplo del patrón solicitud-respuesta.

Intervalo de expiración de mensajes:

En MQTT v5, el intervalo de expiración de mensajes permite que los mensajes tengan una duración configurable. El intervalo de expiración de mensajes se define como el intervalo de tiempo entre el momento en que se publica un mensaje en MQTT broker y el momento en que MQTT broker necesita descartar el mensaje que no se ha entregado. Esta característica es útil en escenarios en los que los mensajes solo son válidos durante una determinada cantidad de tiempo, como comandos sujetos a limitación temporal, streaming de datos en tiempo real o alertas de seguridad. Al establecer un intervalo de expiración de mensajes, MQTT broker puede quitar automáticamente los mensajes obsoletos, lo que garantiza que solo haya información relevante disponible para los suscriptores. Si el intervalo de expiración de un mensaje se establece en cero, significa que el mensaje nunca debe expirar.

Alias de tema:

En MQTT v5, los alias de tema permiten a un cliente usar un alias más corto en lugar del nombre completo del tema en el mensaje publicado. MQTT broker mantiene una asignación entre el alias del tema y el nombre real del tema. Esta característica puede ahorrar ancho de banda de red y reducir el tamaño del encabezado del mensaje, especialmente para temas con nombres largos. Resulta útil en escenarios en los que el mismo tema se publica repetidamente en varios mensajes, como en redes de sensores. MQTT broker admite hasta 10 alias de tema. Un cliente puede usar un campo Alias de tema en el paquete PUBLISH para reemplazar el nombre completo del tema por el alias correspondiente.

Diagrama del ejemplo de alias de tema.

Control de flujo

En MQTT v5, el control de flujo hace referencia al mecanismo para administrar la velocidad y el tamaño de los mensajes que un cliente puede controlar. El control de flujo se puede configurar estableciendo los parámetros Maximum Packet Size (Tamaño máximo de paquete) y Receive Maximum (Recibir máximo) en el paquete CONNECT. El parámetro Receive Maximum permite al cliente limitar el número de mensajes enviados por el agente al número de mensajes que el cliente puede controlar. El parámetro Maximum Packet Size define el tamaño máximo de los paquetes que el cliente puede recibir. MQTT broker tiene un límite de tamaño de mensaje de 512 KiB. Esta característica garantiza la confiabilidad y la estabilidad de la comunicación para dispositivos restringidos con funcionalidades de almacenamiento o velocidad de procesamiento limitadas.

Confirmaciones negativas y paquetes de desconexión iniciados por el servidor

Para MQTT broker v5, Event Grid puede enviar confirmaciones negativas (NACK) y paquetes de desconexión iniciados por el servidor que proporcionan al cliente más información sobre los errores de entrega de mensajes o de conexión. Estas características ayudan al cliente a diagnosticar el motivo de un error y a tomar las acciones de mitigación adecuadas. MQTT broker usa los códigos de motivo definidos en la especificación MQTT v5.

Limitaciones actuales

MQTT broker agregará más características de MQTT v5 y MQTT v3.1.1 en el futuro para alinearse más con las especificaciones MQTT. En la siguiente lista se detallan las diferencias actuales entre las características admitidas por el agente MQTT y las especificaciones MQTT:

Limitaciones actuales de MQTT v5

MQTT v5 difiere actualmente de la especificación MQTT v5 de las siguientes maneras:

  • Todavía no se admiten la suscripciones compartidas.
  • Todavía no se admite la marca Retain.
  • El intervalo de retraso máximo es de 300.
  • La QoS máxima es 1.
  • El tamaño máximo de paquete es de 512 KiB
  • El orden de los mensajes no está garantizado.
  • No se admiten los identificadores de suscripción.
  • Todavía no se admiten los identificadores de cliente asignados.
  • Hay un máximo de 10 alias de tema. El servidor no asigna ningún alias de tema para los mensajes salientes en este momento. Los clientes pueden asignar y usar alias de tema dentro del límite establecido.
  • CONNACK no devuelve la propiedad Response Information incluso si la solicitud CONNECT contiene la propiedad Request Response Information.
  • El servicio no usa las propiedades de usuario en CONNECT, SUBSCRIBE, DISCONNECT, PUBACK, paquetes AUTH, por lo que no son compatibles. Si alguna de estas solicitudes incluye propiedades de usuario, se producirá un error en la solicitud.
  • Si el servidor recibe una PUBACK de un cliente con un código de respuesta de acción no correcta, la conexión finaliza.
  • El tiempo de conexión persistente máximo es de 1160 segundos.

Limitaciones actuales de MQTTv3.1.1

MQTT v5 actualmente difiere de la especificación MQTT v3.1.1 de las siguientes maneras:

  • Todavía no se admiten QoS2 y la marca Retain. Se produce un error en una solicitud de publicación con una marca Retain o con una QoS2 y se cierra la conexión.
  • El orden de los mensajes no está garantizado.
  • El tiempo de conexión persistente máximo es de 1160 segundos.

Ejemplos de código:

Este repositorio contiene ejemplos de código de C#, C y Python que muestran cómo enviar telemetría, enviar comandos y difundir alertas. Los certificados creados con los ejemplos son adecuados para realizar pruebas, pero no son adecuados para entornos de producción.

Pasos siguientes:

Obtenga más información sobre MQTT:

Más información sobre el agente MQTT: