¿Cuál es la diferencia entre una clean session y una sesión persistente en MQTT?

Volver al glosario

Qué estado de sesión guarda el broker

Una sesión MQTT es el estado que un broker mantiene sobre un cliente particular, atado al identificador de ese cliente. Las partes más importantes de ese estado son las suscripciones del cliente - los tópicos que pidió recibir - y cualquier mensaje que llegó a esos tópicos mientras el cliente estaba desconectado, retenido para entrega posterior. Que el broker conserve este estado a través de una desconexión es exactamente lo que la elección de clean session controla. Es la diferencia entre un broker que olvida a un cliente en cuanto se cae y uno que le guarda el lugar puesto.

Con una clean session, el broker trata cada conexión como una pizarra en blanco. Cuando el cliente se desconecta, el broker tira sus suscripciones y cualquier mensaje que estuviera reteniendo; cuando el cliente regresa, debe resuscribirse a todo, y lo publicado en sus tópicos durante el hueco simplemente se perdió. Este es el comportamiento correcto para un cliente que solo quiere datos en vivo y puede restablecerse barato: un tablero que solo quiere lo que está pasando ahora, por ejemplo, no tiene razón para querer un backlog de lecturas viejas al reconectar.

Con una sesión persistente, el broker mantiene vivas las suscripciones del cliente a través de las desconexiones y, de forma crucial, pone en cola los mensajes que califican y llegan mientras el cliente está ausente. Cuando el cliente reconecta con el mismo identificador y pide reanudar, el broker lo reconoce, restaura sus suscripciones sin que el cliente tenga que pedirlo de nuevo y entrega el backlog en cola. El cliente retoma donde se quedó como si nunca se hubiera ido. Esto es lo que usted quiere para un dispositivo que no debe perder datos durante los inevitables huecos de su conexión.

Clean session en 3.1.1 contra clean start y session expiry en MQTT 5

En MQTT 3.1.1 esto es un solo booleano: la bandera clean session. Puesta en verdadero, el broker empieza de cero y no guarda nada tras la desconexión; puesta en falso, el broker mantiene la sesión y pone en cola los mensajes mientras el cliente está fuera. La limitación del modelo 3.1.1 es que una sesión persistente, una vez establecida, la conserva el broker sin expiración incorporada: el estado permanece hasta que el cliente regresa o un administrador lo limpia, lo que puede dejar a los brokers sosteniendo sesiones y mensajes en cola de clientes que quizá nunca vuelvan.

MQTT 5 divide la bandera única en dos controles más expresivos. Hay una bandera clean start que dice si esta conexión particular comienza con una sesión fresca o reanuda una existente, y hay un intervalo de expiración de sesión separado que dice cuánto tiempo debe el broker conservar la sesión después de que el cliente se desconecta. Este desacople es genuinamente útil: un cliente puede empezar limpio pero pedir que su sesión se retenga por un periodo definido, de modo que el broker sostenga su estado y sus mensajes en cola exactamente esa ventana y luego los descarte automáticamente si el cliente no ha vuelto. Resuelve el problema de 3.1.1 de sesiones acumulándose para siempre.

El resultado práctico es un control más fino de la disyuntiva entre confiabilidad y uso de recursos. Un intervalo de expiración corto evita que el broker atesore estado de un cliente que se fue para siempre, mientras que uno más largo protege a un cliente que se espera esté fuera de línea un rato pero volverá. Elegir el intervalo es en realidad una declaración de cuánto tiempo valen los datos de un cliente desconectado, lo que depende por completo del dispositivo y de lo que monitorea.

Comportamiento de reconexión en un enlace celular SCADA inestable

El ajuste cobra vida en el caso que mucho MQTT industrial enfrenta de verdad: un gateway remoto en un enlace celular que se cae repetidamente. La cobertura celular en una localización de pozo remota o un sitio de ducto rara vez es perfecta, y un gateway puede perder su conexión por segundos o minutos muchas veces al día conforme la señal se desvanece o la red conmuta. Si ese gateway se conectó con clean session, cada una de esas caídas borraría sus suscripciones y descartaría lo publicado hacia él durante el hueco, y cada reconexión sería un arranque en frío. Según la dirección del flujo de datos, esa suele ser la receta para perder exactamente los datos que contiene la ventana de la caída.

Una sesión persistente cambia por completo la historia de la reconexión. El gateway se conecta con un identificador de cliente estable y una sesión que el broker retiene, así que cuando el enlace celular se cae y regresa, el broker todavía conoce las suscripciones del gateway y ha estado reteniendo sus mensajes QoS 1 y 2 en cola. Al reconectar, el gateway reanuda sin resuscribirse y recibe el backlog acumulado mientras estuvo a oscuras. Para un dispositivo cuyo trabajo entero es no perder datos de campo a través de un enlace inestable, este es el comportamiento que vuelve confiable a MQTT: la conexión puede rebotar cuanto quiera, y los datos puentean los huecos.

Exactamente por esto una plataforma SCADA en la nube como Merobix empareja sesiones persistentes con niveles de calidad de servicio apropiados para los gateways en conexiones poco confiables: juntos aseguran que una caída celular se convierta en una demora breve y no en un hueco en el registro. La elección de sesión también interactúa con dos características relacionadas de MQTT. Un mensaje retenido es el broker guardando el último valor de un tópico para que un cliente que se suscribe de nuevo reciba el estado actual de inmediato, lo que complementa a una sesión persistente al reconectar. Y el mensaje de testamento (last will) - el aviso que el broker publica si el cliente se desconecta sin despedirse - trabaja junto al estado de sesión para que el resto del sistema sepa que un gateway se quedó callado inesperadamente, de modo que un operador se entere de un enlace muerto en lugar de confiar en silencio en datos viejos.

Preguntas frecuentes