¿Qué es receive maximum y el control de flujo de MQTT?
Cuando un broker tiene mensajes para entregar más rápido de lo que un gateway lento puede aceptarlos, algo tiene que ceder, y sin un límite el broker simplemente seguiría empujando hasta ahogar al gateway. MQTT versión 5 agrega un control exactamente para esto - Receive Maximum - que limita cuántos mensajes pueden estar en vuelo y sin reconocer a la vez, forzando al emisor a pausar hasta que el receptor lo alcance. Esta guía explica qué es Receive Maximum, cómo la ventana en vuelo crea contrapresión y por qué protege de inundaciones a un gateway en un enlace restringido.
Control de flujo de MQTT en una línea: Receive Maximum es un ajuste de MQTT 5 donde cada lado le dice al otro el número máximo de mensajes con calidad de servicio que está dispuesto a tener en vuelo y sin reconocer en un momento dado. Una vez que hay esa cantidad pendiente, el emisor debe detenerse y esperar reconocimientos antes de enviar más, lo que provee contrapresión y evita que un broker rápido inunde con mensajes el enlace lento de un gateway que no puede seguirle el paso.
Mensajes en vuelo y por qué necesitan un límite
Los mensajes enviados con una calidad de servicio que garantiza la entrega no son dispara-y-olvida; cada uno debe reconocerse, y hasta que ese reconocimiento regresa el mensaje está en vuelo - enviado pero aún no confirmado. Un emisor puede tener varios mensajes en vuelo a la vez, habiéndolos enviado sin haber oído de vuelta sobre todos, lo que mantiene ocupada la tubería y alto el caudal. Pero cada mensaje en vuelo es estado que el emisor debe sostener y rastrear, y hay un límite de cuántos tiene sentido tener pendientes antes de que las cosas salgan mal.
El peligro sin límite es un emisor rápido abrumando a un receptor lento. Si un broker tiene un backlog de mensajes para un gateway y simplemente los envía tan rápido como puede, pero el gateway está en un enlace delgado de alta latencia y los procesa despacio, los mensajes sin reconocer se apilan. La memoria se llena de estado en vuelo en ambos lados, el enlace lento se congestiona, y en el peor caso el gateway se cae o la conexión colapsa bajo la carga. El emisor produce más rápido de lo que el receptor puede consumir, sin nada que le diga que frene.
El control de flujo es la respuesta general a ese desajuste: una manera de que un consumidor lento señale a un productor rápido que afloje, igualando la tasa de envío a lo que el receptor realmente puede manejar. En redes esto suele lograrse con una ventana - un tope de cuántos datos sin reconocer pueden estar pendientes - de modo que el emisor llena la ventana y luego espera a que los reconocimientos la reabran antes de enviar más. Receive Maximum trae precisamente esta idea de ventana a la entrega de mensajes con calidad de servicio de MQTT.
Cómo Receive Maximum provee contrapresión
Receive Maximum es un valor que cada lado anuncia al establecerse la conexión: es el número de mensajes con calidad de servicio que ese lado está dispuesto a tener en vuelo y sin reconocer en cualquier momento. En efecto, el receptor le dice al emisor: no tengas más que esta cantidad pendiente conmigo a la vez. Define el tamaño de la ventana en vuelo para esa dirección de la conexión, y lo elige la parte que recibirá, porque es la parte que conoce su propia capacidad de mantener el paso.
El mecanismo crea contrapresión de forma natural. El emisor puede enviar hasta Receive Maximum mensajes, y entonces debe detenerse - no puede enviar uno más hasta que el reconocimiento de alguno anterior regrese y libere un lugar en la ventana. Conforme el receptor avanza con su backlog y reconoce mensajes, se abren lugares y al emisor se le permite enviar más. El ritmo de los reconocimientos del lado lento fija entonces el ritmo de envío del lado rápido, que es exactamente el comportamiento autorregulado que el control de flujo debe proveer.
Esto mantiene acotados y estables a ambos extremos. El emisor nunca sostiene más que un número fijo de mensajes sin reconocer, así que su memoria de estado en vuelo queda topada. Al enlace lento nunca se le empuja más que una ventana de mensajes antes de que el emisor pause, así que no se congestiona bajo una inundación sin límite. Y el receptor dicta el límite que le acomoda, así que un gateway restringido puede fijar una ventana pequeña y protegerse, mientras uno capaz puede fijar una ventana más grande para permitir más caudal. Ese único número afina el intercambio entre caudal y protección.
Control de flujo para gateways de telemetría y SCADA en la nube
La telemetría de campo es un escenario natural para esta clase de contrapresión, porque los dos extremos de una conexión MQTT están tan disparejos. Un broker en la nube es rápido y bien dotado; un gateway remoto vive en un enlace celular o de radio lento y tiene memoria y procesamiento limitados. Cuando comandos, configuración o una ráfaga de mensajes en cola deben bajar al gateway, el broker podría rebasarlo con facilidad. Receive Maximum permite al gateway declarar una ventana en vuelo modesta para que el broker envíe a un ritmo que el gateway realmente pueda absorber, en lugar de inundarlo y arriesgar una conexión caída.
El beneficio se ve más claro alrededor de la recuperación y las ráfagas. Después de que un gateway reconecta y el broker tiene mensajes en cola para él, la tentación del broker es volcar el backlog completo de una vez. En un enlace delgado ese volcado puede congestionar la conexión y tumbar al gateway justo cuando está volviendo. Con un Receive Maximum sensato, el broker alimenta el backlog a través de la ventana al paso del gateway, así que la puesta al día avanza suave y termina en lugar de causar una segunda falla. El control de flujo convierte una inundación riesgosa en un drenado controlado.
Para una plataforma SCADA en la nube como Merobix, este control de flujo a nivel MQTT complementa los otros mecanismos que mantienen sanos los enlaces de campo. Se ubica debajo de las preocupaciones de aplicación y encima del enlace crudo, asegurando que sin importar cuánto tenga que enviarle la plataforma a un gateway, nunca envíe más rápido de lo que el gateway puede reconocer. Eso protege a ambos extremos a través de las conexiones inestables y de bajo ancho de banda de las que dependen los sitios de campo, manteniendo confiable la entrega de mensajes y estables las conexiones aun cuando un gateway lento y una nube rápida tengan apetitos muy distintos de qué tan rápido deben moverse los mensajes.
Preguntas frecuentes
¿Qué limita realmente Receive Maximum de MQTT?
Limita el número de mensajes con calidad de servicio que pueden estar en vuelo y sin reconocer a la vez en una dirección de la conexión. Cada lado anuncia su propio valor al conectar, y una vez que hay esa cantidad de mensajes pendientes, el emisor debe esperar reconocimientos antes de enviar más. No limita los mensajes dispara-y-olvida que no requieren reconocimiento; aplica a los niveles de calidad de servicio con entrega garantizada.
¿Cómo crea contrapresión Receive Maximum?
Al topar la ventana en vuelo, obliga al emisor a detenerse una vez que tiene esa cantidad de mensajes sin reconocer y a esperar a que el receptor reconozca algunos antes de enviar más. Como el receptor solo reconoce tan rápido como puede procesar, el ritmo de reconocimientos del lado lento controla la tasa de envío del lado rápido. Ese comportamiento autorregulado de pausar y reanudar es la contrapresión que evita que un broker rápido inunde a un gateway lento.
¿Por qué un gateway lento necesita control de flujo MQTT?
Porque el broker al que se conecta es típicamente mucho más rápido y con más recursos, y sin un límite podría empujar mensajes, en especial un backlog en cola tras la reconexión, más rápido de lo que el gateway puede aceptar por su enlace delgado. Eso puede llenar la memoria, congestionar el enlace y colapsar la conexión justo cuando el gateway se recupera. Receive Maximum permite al gateway declarar una ventana a la medida de su capacidad para que el broker lo alimente a un ritmo manejable en lugar de inundarlo.
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.