NanoMQ se consolida como un motor de mensajería ligero diseñado para el Edge Computing, actuando como un bus de datos multipprotocolo compatible con MQTT, ZeroMQ y Nanomsg. Su arquitectura permite alternar entre modos con y sin broker, facilitando el desarrollo de aplicaciones distribuidas en entornos IoT.

Con el lanzamiento de la versión 0.8.0, se introducen dos capacidades fundamentales para la interoperabilidad con sistemas externos: un sistema de WebHooks para la gestión de eventos y una API de autenticación basada en HTTP para validar conexiones de clientes.

Sistema de WebHooks para entornos Edge

La implementación de WebHooks en NanoMQ permite capturar eventos internos y reenviarlos a servicios de terceros de forma totalmente asíncrona. Al procesar estas notificaciones en hilos dedicados mediante un canal de comunicación interna (IPC), el rendimiento del broker principal no se ve afectado por la latencia de las peticiones HTTP externas.

Para habilitar esta funcionalidad, se debe editar el archivo de configuración pertinente (generalmente ubicado en /etc/nanomq_web_hook.conf). A continuación, se muestra un ejemplo de configuración para redirigir eventos de conexión y mensajes específicos:

# Activación del plugin
web.hook.enable=true
web.hook.url=http://api-servidor.local:8080/events
web.hook.headers.content-type=application/json

# Definición de reglas de eventos
web.hook.rule.client.connack.1={"action": "on_client_connack"}
web.hook.rule.client.disconnected.1={"action": "on_client_disconnected"}
web.hook.rule.message.publish.1={"action": "on_message_publish", "topic": "sensores/datos/#"}

Actualmente, el sistema soporta los siguientes disparadores:

El formato de los datos enviados (JSON) incluye detallse como el ID del cliente, el nombre de usuario, el topic y el payload, permitiendo una integración transparente con infraestructuras de backend existentes.

Autenticación de conexiones vía HTTP

Para escenarios que requieren una validación dinámica de usuarios, NanoMQ introduce una interfaz de autenticación HTTP. Esto permite delegar la seguridad a un servidor externo, una alternativa robusta a los métodos tradicionales basados en archivos estáticos o plugins obsoletos.

La configuración permite definir el método de envío y los parámetros que se extraerán del paquete CONNECT de MQTT:

# Configuración del servicio de Auth
auth.http.enable = true
auth.http.auth_req.url = http://auth-service.internal/verify
auth.http.auth_req.method = post
auth.http.auth_req.headers.content_type = application/x-www-form-urlencoded

# Mapeo de parámetros del cliente
# %c = Client ID, %u = Username, %P = Password
auth.http.auth_req.params = id_cliente=%c,usuario=%u,clave=%P

El broker considerará la conexión como válida únicamente si el servidor externo responde con un código de estado HTTP 200.

Mejoras operativas y correcciones

Además de las nuevas interfaces de red, la versión 0.8.0 incluye refinamientos técnicos significativos:

• Estandarización de Timestamps: Se ha migrado el campo de marca de tiempo en los eventos de conexión al formato de tiempo UNIX estándar.
• Optimización de Concurrencia: Se resolvieron condiciones de carrera (race conditions) críticas que ocurrían cuando los puentes de red eran cerrados frecuentemente por el extremo remoto.
• Gestión de Mensajes Retenidos: Corrección de un fallo que provocaba el cierre inesperado al procesar propiedades vacías en mensajes configurados como "Retain As Published".
• Validación UTF-8: La verificación de codificación en los mensajes de "Última voluntad" (Will Message) ahora solo se ejecuta si el cliente lo solicita explícitamente, mejorando el rendimiento general.

En el futuro próximo, el ecosistema se expandirá con la inclusión de un motor de reglas nativo para el procesamiento de datos en el borde y el soporte de persistencia en bases de datos locales, optimizando aún más el flujo de datos en arquitecturas IoT descentralizadas.