¿Qué es la opción retain handling de MQTT?
Retain handling es una pequeña opción de suscripción de MQTT 5 con un efecto desproporcionado en el comportamiento al reconectar: decide si suscribirse entrega el mensaje retenido existente del tópico, siempre, nunca, o solo si la suscripción es nueva. Para un cliente SCADA que reconecta y resuscribe constantemente en un enlace inestable, elegir el valor equivocado significa perderse el valor actual o ser inundado con él. Esta página explica los tres ajustes y cuándo conviene cada uno.
Opción retain handling de MQTT en una línea: La opción retain handling de MQTT se fija por suscripción en MQTT 5 y controla si el broker envía el mensaje retenido vigente del tópico al momento de suscribirse. El valor 0 lo envía siempre, el valor 1 lo envía solo si esta suscripción no existía ya, y el valor 2 no lo envía nunca. Existe para que un cliente que reconecta pueda evitar volver a recibir un valor retenido que ya tiene.
Los tres ajustes y qué hacen
Retain handling es una de las opciones de suscripción que van en cada filtro de tópico de un SUBSCRIBE de MQTT 5, junto a las banderas no local y retain as published. Su valor por defecto, 0, preserva el comportamiento clásico de MQTT: cuando usted se suscribe a un tópico que tiene un mensaje retenido, el broker entrega de inmediato ese valor retenido para que usted reciba el último estado conocido enseguida. Para un suscriptor completamente nuevo esto es exactamente lo que quiere: una instantánea inmediata del estado actual.
El valor 1 es el sutil y útil. Dice: envía el mensaje retenido solo si esta suscripción no existía ya en mi sesión. Si el cliente ya estaba suscrito a este tópico y solo está reafirmando la suscripción, el broker omite la entrega del retenido. Está dirigido de lleno al caso de resuscribirse tras reconectar, donde un cliente con sesión persistente que se cayó brevemente no necesita que el broker le vuelva a empujar un valor retenido que recibió hace momentos y todavía conserva.
El valor 2 dice: nunca envíes el mensaje retenido al suscribirse. El cliente seguirá recibiendo las actualizaciones futuras publicadas en el tópico, pero no quiere en absoluto la instantánea retenida preexistente. Esto conviene a un consumidor que solo se interesa en los cambios de ahora en adelante, o a uno que obtiene su estado base por otro canal y encontraría el valor retenido redundante o confuso. Elegir entre los tres es una decisión sobre qué debe significar suscribirse para un estado que quizá usted ya tiene.
Elegir retain handling en un enlace inestable
El ajuste importa más para un cliente que reconecta seguido, lo que describe a casi cualquier consumidor o gateway SCADA en celular. Con una sesión persistente y retain handling en el default 0, cada reconexión y resuscripción vuelve a entregar cada valor retenido al que el cliente se suscribe. Sobre un comodín amplio que cubre miles de tags, eso es una inundación de mensajes retenidos en cada reconexión, la mayoría valores que el cliente ya tenía, desperdiciando el enlace y el procesamiento del cliente justo cuando intenta recuperarse.
Fijar retain handling en 1 en esas resuscripciones cura la inundación. Como la sesión del cliente ya llevaba la suscripción, el broker reconoce la resuscripción y retiene los valores retenidos, entregando solo las actualizaciones genuinamente nuevas. El cliente conserva el estado actual que ya sostenía a través de la desconexión breve y recibe solo lo que de verdad cambió. Esto se empareja naturalmente con una expiración de sesión bien elegida para que la sesión sobreviva las interrupciones cortas en primer lugar.
El criterio se invierte para un arranque en frío. Cuando un cliente conecta limpio sin sesión previa, o después de que su sesión expiró, genuinamente necesita la instantánea retenida para establecer el estado actual, así que ahí el valor 0 es el correcto. Un cliente robusto por lo tanto condiciona su retain handling a cómo se conectó: pide los valores retenidos en una sesión fresca para arrancar su estado, y los suprime en una resuscripción dentro de una sesión existente para evitar reinundarse. Acertar en esto es gran parte de hacer barata la reconexión en un enlace malo.
Preguntas frecuentes
¿Retain handling está disponible en MQTT 3.1.1?
No. Retain handling es una opción de suscripción de MQTT 5. Bajo MQTT 3.1.1 un subscribe siempre entrega el mensaje retenido del tópico, sin manera de suprimirlo en una resuscripción, y por eso un cliente 3.1.1 que reconecta y resuscribe sobre un comodín amplio se reinunda de valores retenidos cada vez. La capacidad de retener los mensajes retenidos en una suscripción existente es uno de los refinamientos de MQTT 5 que ayuda específicamente a los clientes en enlaces inestables a recuperarse barato.
¿Retain handling me impide recibir las actualizaciones futuras?
No. Retain handling solo afecta si el broker envía el mensaje ya retenido en el momento en que usted se suscribe. Sin importar el valor que elija, una vez suscrito continúa recibiendo todos los mensajes futuros publicados en los tópicos coincidentes, incluidas las publicaciones retenidas futuras. El valor 2, nunca enviar al suscribirse, suprime solo la instantánea preexistente; no silencia el flujo en vivo. Un cliente con valor 2 sigue rastreando el tópico hacia adelante, solo no recibe el último valor histórico al suscribirse.
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.