Cómo corregir un bucle de reconexión de cliente MQTT

Primeras revisiones: lea la versión del broker

El registro del broker es el diagnóstico más rápido en MQTT, porque el broker sabe por qué desechó al cliente aunque el cliente no lo sepa. Busque la razón de desconexión adjunta a cada caída: una toma de control por otra conexión con el mismo client ID, una expiración de keep-alive o una falla de autorización se leen distinto en el registro. La versión de MQTT también importa aquí: las revisiones más nuevas del protocolo devuelven un código de razón explícito al cliente al desconectar, mientras que las más viejas a menudo solo cierran el socket, por lo cual el registro del lado del cliente por sí solo puede ser tan poco útil.

El ritmo del bucle es la segunda pista gratis. Un ciclo metronómico de conectar y caer con un periodo fijo sugiere dos clientes tomándose la sesión uno del otro o un keep-alive expirando en horario. Caídas correlacionadas con ráfagas de datos sugieren problemas de carga útil o de autorización al publicar. Caídas correlacionadas con la hora del día o la calidad del enlace apuntan por debajo de MQTT, a la red. Diez minutos observando marcas de tiempo acotan la lista de causas antes de tocar cualquier configuración.

Client IDs duplicados: la pelea por la toma de control

El client ID identifica de forma única una sesión ante el broker, y la especificación es explícita sobre las colisiones: cuando llega un connect que lleva el mismo client ID que una conexión existente, el broker debe desconectar la existente y aceptar la nueva. Dos dispositivos configurados con el mismo ID por lo tanto pelean sin fin: cada conexión expulsa a la otra, el perdedor reconecta, y el bucle corre a la velocidad de sus temporizadores de reintento. Desde la perspectiva del broker esto es comportamiento correcto, no un error, por lo cual nada parece roto salvo el aleteo mismo.

Esto pasa en flotas reales más de lo que debería porque los client IDs se copian y pegan: una configuración de gateway clonada, una plantilla de dispositivo desplegada sin plantillar el ID, una laptop de prueba corriendo la misma configuración que la unidad de campo. La solución es garantizar la unicidad, normalmente derivando el client ID de un número de serie o una dirección MAC en vez de escribirlo. La pista en el registro del broker es la razón de desconexión por toma de control en una conexión en el instante exacto en que la otra conecta; una vez que ve ese emparejamiento, el diagnóstico es seguro.

Keep-alive, intermediarios y rechazos de autenticación

El keep-alive es una promesa del cliente al broker: enviaré algo al menos con esta frecuencia, y un ping si no tengo datos. El broker lo hace cumplir con una vez y media de paciencia: si no sabe nada dentro de una vez y media el intervalo de keep-alive, cierra la conexión y publica la última voluntad del cliente. Un keep-alive afinado en el banco puede ser demasiado ajustado para un enlace celular congestionado donde los paquetes se atascan, así que el broker declara muerto al cliente repetidamente a mitad del atasco. La falla inversa también existe: un keep-alive tan largo que los gateways NAT y firewalls a lo largo de la trayectoria expiran la conexión inactiva primero, y nadie lo nota hasta que la siguiente publicación falla. El rango operativo está acotado por ambos lados, y el valor correcto queda por encima de la duración normal de atasco del enlace y por debajo del tiempo de inactividad más corto de la trayectoria.

Los bucles de autenticación se ven como bucles de conexión pero viven una capa más arriba. El broker acepta la conexión TCP o TLS, lee el paquete connect y lo rechaza: usuario o contraseña malos, una identidad de cliente no autorizada, o un problema de certificado en escuchadores asegurados con TLS. Los clientes simples tratan esto como cualquier otra falla y reintentan de inmediato, produciendo un bucle apretado que hasta puede verse como un ataque al broker en los registros. Relacionada está la variante de lista de control de acceso: el cliente conecta bien, publica en un tema para el que carece de permiso, y los brokers configurados para desconectar ante una violación lo desechan, así que el bucle cicla en cada intento de publicación. Ambas variantes son visibles sin ambigüedad en el registro del broker, por lo cual el paso de la primera revisión se gana su lugar.

Cuándo escalar

Si los IDs están probados como únicos, el keep-alive está dimensionado al enlace real, las credenciales y las listas de control de acceso pasan la revisión, y el bucle persiste, capture un ciclo completo: una traza de paquetes del lado del cliente más el registro del broker para el mismo intervalo. Ese par distingue los sospechosos restantes - un límite de recursos del broker, un problema de renegociación TLS, un error de la biblioteca cliente en el manejo de pings - y es lo que un fabricante de brokers o un mantenedor de bibliotecas pedirá de todos modos. Las tormentas de reconexión de muchos clientes a la vez merecen mención especial: tras un reinicio del broker, miles de clientes reconectando de forma simultánea pueden sobrecargarlo hasta desecharlos de nuevo, por lo cual los clientes bien portados agregan un retroceso aleatorio a sus temporizadores de reintento.

El aleteo importa más allá del ruido porque cada caída anormal dispara el mensaje de última voluntad del cliente, y cada suscriptor ve al dispositivo parpadear entre fuera y dentro de línea. Para una plataforma SCADA como Merobix que consume datos MQTT, un cliente que aletea significa vaivén de estado y huecos, así que la vista del lado de la plataforma sobre la estabilidad de la conexión es en sí un artefacto útil de escalamiento: muestra exactamente cuándo empezó el vaivén, lo cual suele alinearse con un despliegue de configuración o un cambio de red que alguien puede nombrar.

Preguntas frecuentes