¿Qué es el intervalo de expiración de mensajes de MQTT?
El intervalo de expiración de mensajes es una propiedad de MQTT 5 que pone fecha de caducidad a un mensaje que el broker retiene para un suscriptor fuera de línea. Para el SCADA, donde un flujo de hace dos minutos puede ser peor que ningún valor, es la característica que evita que un cliente al reconectar sea inundado con lecturas viejas. Esta página explica qué hace la propiedad, cómo la descuenta el broker y dónde se gana su lugar en un diseño de telemetría.
Intervalo de expiración de mensajes MQTT en una línea: El intervalo de expiración de mensajes de MQTT es una propiedad por publicación, nueva en MQTT 5, que le dice al broker cuántos segundos puede permanecer un mensaje en la cola de un suscriptor antes de descartarse sin entregar. Cuando un mensaje QoS 1 o 2 queda en cola para un cliente fuera de línea, el broker descuenta el intervalo; si el cliente no ha reconectado cuando llega a cero, el mensaje se descarta en lugar de entregarse viejo.
Qué controla la propiedad
La expiración de mensajes la fija el publicador en un paquete PUBLISH individual como una de las propiedades de MQTT 5. Solo importa cuando un mensaje no puede entregarse de inmediato, lo que en la práctica significa que quedó en cola para un suscriptor cuya sesión sigue viva pero cuya conexión de red está caída en ese momento. Para un mensaje que se entrega enseguida, el intervalo es irrelevante. Es una regla sobre cuánto tiempo un mensaje almacenado sin entregar sigue valiendo la pena entregarse.
El broker trata el intervalo como una cuenta regresiva. Registra cuánto lleva esperando el mensaje y, cuando el suscriptor por fin reconecta, reenvía el mensaje con el intervalo de expiración reducido por el tiempo transcurrido. Si ese tiempo transcurrido excede el intervalo original, el broker descarta el mensaje y el suscriptor nunca lo ve. Esto es fundamentalmente distinto del dispara-y-olvida de QoS 0; la expiración solo interactúa con los mensajes en cola que crean las sesiones persistentes y QoS 1 o 2.
Es importante no confundir la expiración de mensajes con la expiración de sesión ni con los mensajes retenidos. La expiración de sesión gobierna cuánto conserva el broker la suscripción y la cola completas de un cliente tras su desconexión. Un mensaje retenido es el último valor conocido que el broker entrega a un suscriptor recién llegado. La expiración de mensajes es más estrecha que ambos: es la vida útil de una publicación específica en cola. Las tres pueden estar en juego a la vez para el mismo cliente.
Por qué la telemetría vieja es un problema que vale resolver
Considere un gateway que publica un nivel de tanque cada pocos segundos con QoS 1, y un consumidor en la nube que pierde brevemente su conexión. Con una sesión persistente y sin expiración, el broker pone fielmente en cola cada lectura de nivel durante la interrupción y entrega el backlog completo en el instante en que el consumidor reconecta. El consumidor recibe entonces una ráfaga de lecturas con minutos de antigüedad, en orden, y si las escribe ingenuamente en un historiador registra un valor viejo como si fuera actual, o se atraganta con un backlog antes de alcanzar la realidad.
Fijar un intervalo de expiración modesto en esas publicaciones de telemetría cambia el comportamiento hacia lo que un sistema de control realmente quiere. Durante una interrupción corta solo sobreviven las lecturas más jóvenes que el intervalo; lo más viejo lo descarta el broker. El consumidor reconecta y recibe solo la historia reciente o, en el caso extremo, solo valores todavía lo bastante frescos para importar. Para un valor de proceso en vivo, entregar la lectura actual y descartar el backlog viejo es casi siempre el intercambio correcto, y evita que la ruta de ingestión haga trabajo inútil, una preocupación compartida con la ingestión de MQTT a una base de datos de series de tiempo.
El criterio es por tipo de dato. Los valores de proceso en vivo quieren una expiración corta para que nadie actúe sobre datos viejos. Ciertos mensajes de evento o comando no quieren expiración alguna, porque un cambio de setpoint perdido o un reconocimiento de alarma perdido no es algo que usted quiera descartado en silencio solo porque el destinatario estuvo fuera de línea un rato. Decidir la expiración por tópico, en lugar de aplicar un valor general, es lo que separa un diseño pensado de un default copiado.
Preguntas frecuentes
¿La expiración de mensajes está disponible en MQTT 3.1.1?
No. El intervalo de expiración de mensajes es una de las propiedades de MQTT 5 y no tiene equivalente en 3.1.1. Bajo 3.1.1, un broker que retiene mensajes QoS 1 o 2 en cola para una sesión persistente los entrega todos al reconectar sin noción alguna de antigüedad, que es exactamente el problema del backlog viejo que la expiración de mensajes vino a resolver. Si el manejo de telemetría vieja importa en su diseño, es una de las razones concretas para correr MQTT 5 de extremo a extremo.
¿La expiración de mensajes aplica a los mensajes retenidos?
Sí, y conviene saberlo. Si un publicador fija la bandera de retención y un intervalo de expiración de mensajes, el broker conserva el valor retenido solo hasta que el intervalo vence, y luego lo elimina. Esto permite que un último valor conocido expire por sí solo en lugar de quedarse para siempre después de que un nodo se fue. Sin expiración, un mensaje retenido persiste en el tópico hasta que se sobrescribe o se limpia explícitamente, lo que puede dejar un valor muy viejo entregándose a suscriptores nuevos.
Fuentes y lecturas
Referencias primarias de los organismos de normas y reguladores que definen este tema:
- MQTT Version 5.0 Specification - OASIS
Servicios de automatización
¿Necesita convertir esta información en un sistema que funcione?
Merobix integra SCADA, programa PLC Allen-Bradley y Siemens, y diseña y fabrica tableros de control industrial.
Las solicitudes de reunión se revisan antes de confirmarse.