¿Qué son MQTT no local y retain as published?
No local y retain as published son dos opciones de suscripción de MQTT 5 que resuelven problemas que muerden en cuanto usted construye un puente o un cliente bidireccional. No local evita que un publicador oiga su propio eco; retain as published mantiene intacta la bandera de retención a través de un salto. Para un integrador que cablea brokers entre sí, son la diferencia entre un tejido limpio y un bucle de mensajes. Esta página explica ambas y dónde importa cada una.
MQTT no local y retain as published en una línea: La opción de suscripción no local de MQTT le dice al broker que no le envíe a un cliente los mensajes que ese mismo cliente publicó, evitando un eco. La opción retain as published le dice al broker que conserve la bandera de retención original en los mensajes que reenvía, en lugar de limpiarla, lo que importa cuando un cliente republica o puentea mensajes y debe preservar su condición de retenidos.
No local: no oír su propio eco
Por defecto en publicación/suscripción, si un cliente publica en un tópico y a la vez se suscribe a un patrón que lo cubre, el broker le entrega de regreso su propio mensaje. Normalmente inofensivo, pero se vuelve un problema real en dos situaciones. La primera es un cliente bidireccional que actúa como fuente y destino en tópicos que se traslapan y no quiere procesar su propia salida. La segunda, más seria, es un puente que se suscribe a un tópico para reenviarlo, porque sin cuidado el mensaje reenviado puede regresar directo y formar un bucle.
La opción no local, fijada por suscripción en MQTT 5, instruye al broker simplemente a no entregarle a un cliente ningún mensaje que ese mismo cliente publicó en esa suscripción. Suprime limpiamente el eco en la fuente. Esta es la propiedad que vuelve seguro el puenteo entre brokers, porque un puente puede suscribirse con no local activado y saber que nunca recibirá de regreso los mismísimos mensajes que acaba de reenviar, que es la causa clásica de una tormenta en un puente MQTT configurado con ingenuidad.
Hay una restricción que vale conocer: no local no puede usarse con una suscripción compartida. Como una suscripción compartida se reparte deliberadamente entre un grupo de clientes en lugar de atarse a una identidad, la noción de que un mensaje sea de este cliente no está bien definida para el grupo, así que la especificación prohíbe la combinación. Rara vez es una limitación en la práctica, porque el problema del eco es una preocupación de cliente único que no surge igual en un grupo de consumidores balanceado.
Retain as published: preservar la bandera a través de un salto
Normalmente, cuando el broker entrega un mensaje a un suscriptor, limpia la bandera de retención en la copia que entrega, salvo que el mensaje se envíe por ser el valor retenido de una suscripción nueva. Este default evita que los suscriptores ordinarios malinterpreten tráfico en vivo como estado retenido. Pero causa problemas a un puente, porque un puente se suscribe para recibir mensajes y luego los republica en otro broker, y si la bandera de retención se le quitó a la entrada, el mensaje republicado pierde su condición de retenido y el segundo broker ya no guarda un último valor conocido.
La opción retain as published, también fijada por suscripción, le dice al broker que deje la bandera de retención exactamente como la puso el publicador original en los mensajes que reenvía a este suscriptor. Un puente que se suscribe con retain as published ve cada mensaje entrante con su verdadera condición de retenido intacta, así que al republicar puede reproducir con fidelidad si el valor debe quedar retenido del otro lado. Esto mantiene consistente el estado retenido a través de un tejido multibroker.
Ambas opciones son, al final, herramientas para el mismo público: gente que construye tejidos y no sistemas de un solo broker. Un gateway solitario hablando con un broker rara vez necesita alguna. En cuanto usted introduce un segundo broker, un puente o un cliente bidireccional, no local previene bucles y autoprocesamiento, y retain as published preserva la semántica de último valor conocido que un puente ingenuo destruiría en silencio. Recurrir a ellas es señal de que ya pasó la topología más simple y está en integración de verdad.
Preguntas frecuentes
¿Por qué no puedo usar no local con una suscripción compartida?
Porque las dos ideas chocan a nivel de identidad. No local significa no me devuelvas los mensajes que yo publiqué, lo que exige que el broker sepa que este cliente fue el publicador. Una suscripción compartida reparte deliberadamente los mensajes entre un grupo de clientes que no se tratan como una sola identidad publicadora, así que el concepto de que un mensaje sea de este cliente no está bien definido para el grupo. La especificación de MQTT 5 prohíbe por lo tanto fijar no local en una suscripción compartida, y los brokers rechazan la combinación.
¿Cuándo importa realmente retain as published?
Principalmente al puentear brokers. Un puente se suscribe a un broker de origen y republica en un broker de destino. Sin retain as published, el broker limpia la bandera de retención en la copia que el puente recibe, así que el puente no puede saber qué mensajes eran retenidos y sus copias republicadas pierden esa condición, dejando al broker de destino sin último valor conocido en esos tópicos. Con retain as published, la bandera original sobrevive el salto, así que el puente puede preservar fielmente el estado retenido a través de todo el tejido.
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.