Características de MQTT compatibles con el corredor MQTT de Azure Event Grid

Transporte de telemetría de cola de mensajes (MQTT) es un protocolo de transporte de mensajería de publicación y suscripción diseñado para entornos restringidos. MQTT es eficaz, escalable y confiable, lo que hace que sea popular para la comunicación en escenarios de Internet de las cosas (IoT). El corredor MQTT admite clientes que publican y suscriben mensajes mediante MQTT v3.1.1, MQTT v3.1.1 a través de WebSocket, MQTT v5 y MQTT v5 a través de WebSocket. El corredor MQTT también admite la comunicación entre versiones MQTT (MQTT 3.1.1 y MQTT 5).

El corredor MQTT de Azure Event Grid también admite dispositivos y servicios que envían mensajes MQTT sobre HTTPS, lo que simplifica la integración con clientes que no son MQTT. Event Grid permite enviar mensajes MQTT a la nube para el análisis de datos, el almacenamiento y las visualizaciones, entre otros casos de uso. Esta funcionalidad actualmente está en su versión preliminar.

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.
• Comunicación más transparente con los clientes mediante 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 mediante Seguridad de la capa de transporte (TLS) 1.2 o TLS 1.3. Si intenta omitir este paso, se producirá un error en la conexión.

Al conectarse al corredor MQTT, use los siguientes puertos durante la comunicación mediante MQTT:

• MQTT v3.1.1 y MQTT v5 en el puerto TCP 8883
• MQTT v3.1.1 sobre WebSocket y MQTT v5 sobre 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 utilizar valores diferentes para ClientId en cada una de sus sesiones.
• El campo Username es necesario si no ha seleccionado 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 Username. Ese nombre debe coincidir con el nombre de autenticación proporcionado y el valor en el campo de certificado del cliente que se ha especificado durante la creación del recurso de cliente.

Más información sobre la autenticación de cliente.

Compatibilidad con varias sesiones

La compatibilidad con sesiones múltiples permite a los clientes MQTT de la aplicación tener una implementación más escalable y confiable mediante la conexión al corredor MQTT 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. Para configurar varias sesiones por cliente en Azure Portal, siga estos pasos:

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

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 la sesión, por ejemplo, si hay uno o más valores para el id. de cliente para cada nombre de usuario.

Por ejemplo, las siguientes combinaciones de Username y ClientId en el paquete CONNECT permiten al cliente Mgmt-application conectarse al corredor MQTT en tres sesiones independientes:

• Primera sesión:
  • Username: Mgmt-application
  • ClientId: Mgmt-Session1
• Segunda sesión:
  • Username: Mgmt-application
  • ClientId: Mgmt-Session2
• Tercera sesión:
  • Username: Mgmt-application
  • ClientId: Mgmt-Session3

Para más información, vea Establecimiento de 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 asignada en ese momento para el cliente A, se rechaza la solicitud de conexión del cliente B. Pero 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 y,después, 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. El cliente A se conecta con una sesión persistente 123 y, después, se desconecta. El cliente A no se puede conectar con una nueva sesión 456 porque 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

El corredor MQTT de Event Grid admite las siguientes características de MQTT.

Calidad del servicio

El corredor MQTT admite los niveles de calidad de servicio (QoS) 0 y 1, que definen la garantía de entrega de mensajes en los paquetes PUBLISH y SUBSCRIBE entre los clientes y el corredor MQTT.

• QoS 0 garantiza la entrega como máximo: el suscriptor no reconoce mensajes con QoS 0 y el publicador no los retransmite.
• QoS 1 garantiza al menos una entrega: el suscriptor reconoce los mensajes y el publicador los retransmite si no se han confirmado.

QoS permite a los clientes controlar la eficiencia y confiabilidad de la comunicación.

Sesiones persistentes

El corredor MQTT admite sesiones persistentes para MQTT v3.1.1 de forma que el corredor MQTT conserve información sobre la sesión de un cliente cuando se desconecta para garantizar la confiabilidad de la comunicación. Esta información incluye las suscripciones del cliente y los mensajes de QoS 1 que faltan o no se reconocen. Los clientes pueden configurar una sesión persistente si establecen la marca cleanSession del 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 permite a un cliente iniciar una nueva sesión con el corredor MQTT después de descartar los datos de sesión anteriores. La expiración de la sesión permite a un cliente informar al corredor MQTT 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. Un cliente también puede establecer un intervalo de expiración de sesión breve por motivos de seguridad o para evitar posibles conflictos de datos que podrían haberse producido durante la sesión anterior. Un cliente también puede establecer la marca Clean Start 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 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 de intervalo de expiración de sesión en el paquete CONNECT. Se ajusta cualquier valor que supere el límite. El valor predeterminado de esta propiedad de espacio de nombres es de una hora y puede extenderse hasta ocho horas. Para configurar el intervalo máximo de expiración de la sesión en Azure Portal, siga estos pasos:

1. En Azure Portal, vaya a su espacio de nombres.
2. En Configuración, cambie el valor de Intervalo máximo de expiración de sesión en horas al límite que quiera.
3. Seleccione Aplicar.

Desbordamiento de sesión

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

Mensajes de última voluntad y testamento

Última voluntad y Testamento (LWT) notifica a sus clientes MQTT las desconexiones bruscas de otros clientes MQTT. Puede usar LWT para garantizar un flujo predecible y confiable de comunicación entre los clientes MQTT durante las desconexiones inesperadas. Esta funcionalidad es valiosa para escenarios en los que la comunicación en tiempo real, la confiabilidad 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 Will del paquete CONNECT durante la conexión. Cuando el cliente se desconecta abruptamente, el corredor MQTT publica el mensaje Will 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 mayor que 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 Will no se publica.

Propiedades de usuario

El corredor MQTT admite propiedades de usuario en paquetes PUBLISH de MQTT v5 que puede usar para 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 controlarlo 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 uno con el propósito de "información".

Patrón de solicitud-respuesta

MQTT v5 introdujo campos en el encabezado de paquete MQTT PUBLISH 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.

Intervalo de expiración del mensaje

En MQTT v5, el intervalo de expiración del mensaje permite que los mensajes tengan una duración configurable. El intervalo de expiración del mensaje se define como el intervalo de tiempo entre la hora a la que se publica un mensaje en el corredor MQTT y la hora en que el agente necesita descartar el mensaje no entregado. Esta característica es útil en escenarios en los que los mensajes son válidos solo durante una determinada cantidad de tiempo, como comandos sensibles al tiempo, streaming de datos en tiempo real o alertas de seguridad. Al establecer un intervalo de expiración de mensajes, el corredor MQTT puede quitar automáticamente los mensajes obsoletos. Este paso 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. El corredor MQTT 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. El corredor MQTT admite hasta 10 alias de tema. Un cliente puede usar un campo Topic Alias en el paquete PUBLISH para reemplazar el nombre completo del tema por el alias correspondiente.

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. Para configurar el control de flujo, establezca los parámetros Maximum Packet Size y Receive Maximum 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. El corredor MQTT tiene un límite de tamaño de mensaje de 512 KiB. Esta característica garantiza la confiabilidad y estabilidad de la comunicación para dispositivos restringidos con funcionalidades limitadas de velocidad de procesamiento o almacenamiento.

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

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

Orden de los mensajes

MQTT v5 garantiza la entrega de mensajes en orden dentro de cada tema y cada cliente cuando se usa el nivel 1 de QoS, que es fundamental para los flujos de trabajo que requieren integridad de secuencia. Es ideal para escenarios como telemetría, ejecución de comandos y datos de serie temporal.

Sin embargo, no garantiza la ordenación en distintos temas o cuando los mensajes se envían con distintos niveles de QoS. Para más información, póngase en contacto con nosotros en askmqtt@microsoft.com.

Identificadores de cliente asignados

MQTT v5 presenta compatibilidad con identificadores de cliente asignados, lo que permite al corredor MQTT generar y devolver un identificador de cliente único cuando el cliente no proporciona uno. La compatibilidad con el corredor MQTT con esta característica garantiza la incorporación directa de clientes y reduce la necesidad de que los clientes administren sus propios identificadores. Es especialmente útil en escenarios en los que el aprovisionamiento de clientes es dinámico o cuando los dispositivos no tienen ninguna identidad preconfigurada. Los identificadores de cliente asignados se pueden recuperar de la respuesta CONNACK y reutilizarse para sesiones futuras para mantener una identificación coherente.

Administración del identificador de cliente y los límites de sesión en MQTT

• Los identificadores de cliente asignados permiten a los clientes conectarse sin especificar identificadores predefinidos, lo que permite sesiones temporales o persistentes.
• Los clientes pueden evitar que se bloquee mediante intervalos de expiración de sesión breves durante la primera conexión y guardar el identificador de cliente asignado para su uso futuro.
• En el caso de las actualizaciones o restablecimientos de firmware, los clientes deben conservar su identificador de cliente conocido o usar intervalos de expiración de sesión modestos para evitar bloqueos prolongados.
• La configuración del espacio de nombres puede aumentar los límites de sesión por cliente para minimizar las interrupciones durante las actualizaciones o reversiones.

Limitaciones actuales

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

Limitaciones actuales de MQTT v5

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

• Todavía no se admiten las suscripciones compartidas.
• El intervalo de retraso máximo de Will es 300.
• La QoS máxima es 1.
• El tamaño máximo de paquete es de 512 KiB.
• No se admiten los identificadores de suscripción.
• El número máximo de alias de tema es 10. 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 aunque la solicitud CONNECT contenga la propiedad Request Response Information.
• Las propiedades de usuario en los paquetes CONNECT, SUBSCRIBE, DISCONNECT, PUBACK y AUTH no se usan en el servicio, por lo que no se admiten. Si alguna de estas solicitudes incluye propiedades de usuario, se producirá un error en la solicitud.
• Si el servidor recibe un paquete PUBACK de un cliente con un código de respuesta que no es correcto, la conexión finaliza.
• El valor máximo de mantener la conexión es de 1160 segundos.

Limitaciones actuales de MQTTv3.1.1

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

• No se admite QoS 2. Se produce un error en una solicitud de publicación con una marca RETAIN o con una instancia de QoS 2 y se cierra la conexión.
• El valor máximo de mantener la conexión 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 alertas de difusión. Los certificados creados con los ejemplos son adecuados para realizar pruebas, pero no son adecuados para entornos de producción.

Contenido relacionado

Para más información sobre MQTT, vea la especificación MQTT v5. Para más información sobre el corredor MQTT, vea lo siguiente:

• Autenticación de clientes
• Establecimiento de varias sesiones para un solo cliente