MQTT QoS, mensajes retenidos y sesiones persistentes

Las opciones de entrega MQTT sirven sólo cuando coinciden con el significado del mensaje. QoS, estado retenido, sesiones y wills controlan comportamiento de protocolo entre clientes y broker. No vuelven fresco un valor, no confirman efecto físico ni reemplazan enclavamientos locales y propiedad de seguridad.

Leé la tabla QoS literalmente

QoS	Intención de entrega MQTT	Consecuencia de aplicación
0	Como máximo una vez	Puede perderse; no hay handshake de retransmisión
1	Al menos una vez	El receptor puede ver duplicados
2	Exactamente una vez dentro del flujo MQTT	Más handshake y estado; no exactamente una vez en proceso

QoS 0 sirve para telemetría no crítica de alta tasa cuando una muestra nueva pronto reemplaza una vieja. QoS 1 sirve para eventos o alarmas cuando la aplicación tolera duplicados. QoS 2 agrega intercambios y estado, por eso usalo sólo si costo y fallas lo justifican. El acuse del broker en cualquier QoS dice que manejó la operación de protocolo; no confirma escritura de historiador, movimiento, acción operativa ni estado seguro.

Tratá DUP como información de transporte

La marca DUP indica semántica de retransmisión. No identifica un evento de negocio ni puede decidir que un consumidor ya aplicó una operación. Incluí event_id estable en eventos y hacé idempotente al consumidor: guardar la misma transición de alarma dos veces no debe crear dos órdenes, y repetir estado no debe disparar otra acción.

Una secuencia puede ayudar dentro de época de fuente, pero reglas de reconexión y reset deben ser explícitas. No uses orden de llegada broker como orden universal entre publicadores. Identidad, orden y compensación siguen siendo responsabilidades de aplicación incluso con QoS 2.

Entendé el estado retenido

Una publicación retained guarda un último mensaje por tópico y lo entrega a suscriptores posteriores que coincidan. Es estado conocido más reciente, no flujo histórico. Publicá payload retained vacío para borrarlo. El estado retenido existe fuera de sesión de suscriptor, por eso un cliente nuevo o limpio puede recibirlo.

Todo contrato retained necesita tiempo de fuente y frescura. Un valor retenido puede tener horas después de falla o partición. Consumidores deben verificar instante medido, calidad y vencimiento antes de usarlo. Nunca uses retained solo como prueba de actuador apagado, guarda cerrada o proceso seguro.

Separá Clean Start de Session Expiry

Clean Start indica si broker descarta estado de sesión existente al conectar. Session Expiry indica cuánto puede sobrevivir ese estado al desconectar. Según sesión negociada, puede incluir suscripciones, mensajes QoS en cola y flujos QoS incompletos. No conserva memoria arbitraria de aplicación ni vuelve sano a un cliente desconectado.

Elegí persistencia según rol. Un dashboard descartable puede usar Clean Start y suscribirse de nuevo. Un colector que necesita entrega QoS 1 offline acotada puede pedir Session Expiry breve e intencional y monitorear límites. Persistencia larga sin cuotas sólo traslada la caída a presión de almacenamiento broker.

Vencé mensajes antes que las colas

Message Expiry Interval limita cuánto sigue útil una publicación. Es distinto de Session Expiry y de borrar retained. Colas offline de broker y cliente son finitas: definí límites de bytes y cantidad, comportamiento de vencimiento y alarma antes de que backlog sea disponibilidad.

Telemetría vencida no debe reproducirse como actual. Para eventos, decidí si entrega tardía sirve, necesita ruta de dato tardío o se descarta con brecha visible. Dimensioná buffers store-and-forward separados de colas broker y documentá qué capa posee cada retención.

Usá Last Will dentro de su límite

Last Will puede avisar que terminó inesperadamente una conexión. Will Delay puede demorar publicación, Will Retain retener aviso y expiry limitar visibilidad. Ayudan a comunicar estado de conexión, no estado de proceso.

Un will puede demorarse por caída transitoria, suprimirse por desconexión limpia o llegar mientras equipo de campo sigue operando. No lo mapees directo a safe/off, parada de emergencia ni lógica permisiva. Esas funciones necesitan señales locales, diseño apto cuando aplique y respuesta de timeout aprobada.

Elegí configuración por propósito

Para telemetría no crítica de alta tasa, usá QoS 0, sin retained y Message Expiry corto si dato viejo no sirve. El riesgo es tratar paquetes faltantes como alarma sin regla de frescura separada.

Para alarmas o eventos discretos, usá QoS 1, event_id, consumidores idempotentes, Session Expiry acotado para colector si hace falta y política explícita de evento tardío. El riesgo es asumir que QoS 1 elimina duplicados.

Para configuración conocida o estado de conectividad, usá mensaje retained con tiempo de fuente, calidad y vencimiento definido. Una política de sesión corta puede servir al publicador, pero retención es independiente. El riesgo es mostrar estado retained viejo como hecho operativo vivo.

Asegurá el límite de tópicos

Usá TLS cuando soporte, ACL por tópico que limite identidades publicadoras y suscriptoras, zoning de red y mínimo privilegio. Una identidad de telemetría no debe publicar comandos y un suscriptor cloud no debe obtener ruta a control PLC o fieldbus. Rotá credenciales por proceso aprobado y no pongas secretos en payloads, logs ni ejemplos.

Guías NIST y CISA ubican broker dentro de arquitectura OT. Una ruta cómoda a Internet no sustituye segmentación, acceso remoto revisado ni propiedad de interfaz expuesta.

Corré un checklist operativo

Confirmá QoS por propósito; event_id y duplicados; creación, reemplazo y borrado retained; Clean Start y Session Expiry; Message Expiry y límites; will demorado; ACL y TLS; y reglas de frescura. Probá reinicio broker, reconexión cliente, duplicado, retained vencido, cola offline llena y mensajes expirados.

Seguí con diseño de payload MQTT, ciclo de vida Sparkplug, store-and-forward resiliente y servicios IIoT cloud.