MQTT (Message Queuing Telemetry Transport) es uno de los protocolos de mayor relevancia actualmente en proyectos dentro del contexto de la IoT. Este popular estándar de Oasis proporciona soluciones de sencilla implementación a problemas que se suelen dar en este dominio y que presentan bastantes retos para otros protocolos. Esto es especialmente destacable en comparaciones con HTTP, un protocolo cuya presencia en la IoT se puede explicar en parte por su popularidad, particularmente por ser una de las bases de la Web.
MQTT adopta un patrón de publicación y subscripción, en contraste con la petición y respuesta de HTTP. Los clientes mantienen una conexión activa con un componente central llamado broker, que les permite llevar a cabo dos acciones a alto nivel. Por un lado un cliente puede publicar mensajes en el broker bajo un tópico—nombres que identifican grupos de mensajes con una temática común. Por otro lado, un cliente puede suscribirse a un tópico para recibir todos los mensajes publicados en él por todos los demás clientes del broker.
Es importante destacar que el broker es agnóstico desde el punto de vista de la aplicación. Los nombres de los tópicos y el flujo de publicaciones-suscripciones están bajo el control del desarrollador, que tiene capacidad para diseñar la aplicación como crea conveniente. Esto permite que existan un conjunto de implementaciones reutilizables de brokers de calidad contrastada, varias de ellas open source (por ejemplo Eclipse Mosquitto).
Esta aproximación en la que el broker actúa como intermediario de todas las comunicaciones tiene una serie de ventajas:
- El broker libera a los clientes de la responsabilidad de mantener una comunicación individual con todos los receptores de sus mensajes. Esto simplifica la escalabilidad a medida que se añaden clientes a la red.
- Las comunicaciones son más ligeras—se necesita un volumen de transferencia menor para transmitir la misma información. Esto es de especial interés en despliegues IoT, que raramente utilizan conexiones con cuotas de transferencia ilimitadas (por ejemplo, 3G).
- Los clientes no tienen que mantener un puerto escuchando al exterior para recibir comunicaciones iniciadas desde otros nodos. Esto añade una complejidad notable cuando se trabaja con dispositivos con tendencia a dormir para optimizar el consumo de batería, o desplegados sobre transportes donde las direcciones IP fijas son un recurso de difícil acceso.
Los clientes pueden acogerse a tres niveles diferenciados de calidad de servicio (QoS) que pueden ser definidos para cada mensaje publicado de manera individual, y para el conjunto de los mensajes de una suscripción. El nivel más permisivo (QoS 0) es el más rápido y con menor consumo de datos, pero no garantiza la entrega de los mensajes; esto es adecuado en situaciones donde los mensajes individuales no son críticos (por ejemplo, niveles de temperatura de un sensor) y se puede aceptar la pérdida de alguno de ellos. El nivel intermedio (QoS 1) garantiza la entrega, pero tiene la desventaja de que el mensaje puede ser recibido más de una vez, lo que obliga a implementar lógica de control adicional en la aplicación. El nivel superior (QoS 2) garantiza la entrega y evita las repeticiones, pero presenta los mayores requisitos en datos y computación. Escoger apropiadamente los niveles de QoS para cada una de las interacciones es una de las tareas de diseño más relevantes para poder conseguir un balance adecuado entre velocidad e integridad de la aplicación.
La funcionalidad de sesiones persistentes ofrecida por MQTT está estrechamente relacionada con los niveles de QoS. Un cliente tiene la opción de configurar su conexión con el broker para que los datos de sesión se almacenen y sean fácilmente recuperables si la conexión se pierde temporalmente. Estos datos incluyen mensajes con QoS 1 o 2 recibidos durante un periodo offline, así como las suscripciones activas—de esta manera se evita que el cliente tenga que crear las suscripciones de nuevo después de reconectarse.
En CTIC usamos MQTT frecuentemente, especialmente cuando se necesita facilitar la intercomunicación entre sensores y actuadores en despliegues con un alto número de nodos de capacidades limitadas. Un ejemplo concreto de esto lo encontramos en el proyecto ITINERA2, donde los gateways de localización desplegados en campo publican los identificadores de las pulseras RFID de deportistas, para que posteriormente los componentes de backend que están suscritos a esos tópicos puedan insertarlos en el pipeline de procesamiento.
Aunque la versión más extendida actualmente es la 3.1.1 (lanzada en 2014), la versión 5 ha aparecido recientemente coincidiendo con su 20 aniversario. MQTT 5 presenta novedades muy interesantes, como la capacidad de definir explícitamente la vida máxima de los mensajes (que previamente debían ser almacenados de manera indefinida hasta la reconexión del cliente); la posibilidad de crear suscripciones compartidas para facilitar la escalabilidad horizontal y el procesamiento de suscripciones con grandes volúmenes de mensajes; o el soporte para cabeceras con metadatos en los mensajes, que previamente debían ser implementadas dentro del contenido del mensaje por la propia lógica de aplicación.
Considerando la extensión y madurez del protocolo, y el soporte proporcionado por la comunidad, es razonable esperar que la presencia de MQTT en el contexto de la IoT siga creciendo, afianzándose como el protocolo de mensajería pubsub estándar de facto.
