MQTT: El estándar para la mensajería de IoT

MQTT es un protocolo de transmisión de mensajes, que permite la publicación y suscripción entre un cliente y un servidor. Es liviano, abierto, simple y diseñado para ser fácil de implementar. Esto lo hace ideal para ser utilizado con dispositivos que tienen que estar en ambientes restringidos como en aplicaciones de comunicación Machine to Machine (M2M) o en el internet de las cosas (IoT) debido a las exigencias de eficiencia en consumo de energía y de ancho de banda que estos ambientes requieren.

El origen del protocolo

Fue inventado en IBM por Andy Standford-Clark y Arien Nipper, se necesitaba un protocolo con un consumo mínimo de batería y de ancho de banda, así que entre ambos hicieron una lista de las características que debía tener:

• Implementación simple
• Calidad en el servicio de entrega
• Eficiente en peso y uso de ancho de banda
• Agnóstico de datos
• Conocimiento de sesión continua

Aún al día de ahora estas características se mantienen para el protocolo MQTT, aunque la principal aplicación de este cambio para ser utilizado en equipos embebidos privativos una solución para aplicaciones de internet de las cosas. Este cambio de enfoque hizo que se creara ciertas confusiones con el nombre del protocolo.

El nombre viene de un protocolo que fue desarrollado en 1999 para un producto en específico de IBM que se llamaba MQ; algunas personas por eso piensan que MQTT es un protocolo de mensajes en cola, pero esto es incorrecto MQTT no es un protocolo de mensajes en cola como tal, aunque es posible poner mensajes en cola bajo ciertas circunstancias utilizando este protocolo. En 2010, salió una versión de este protocolo libre de regalías y fue cuando prácticamente cualquiera es libre de utilizarlo e implementarlo.

MQTT significa MQ Series telemetry transport, lo que vendría siendo algo así como transporte de telemetría para equipos serie MQ.

MQTT: dinámica de publicador y suscriptor

La dinámica de publicador y suscriptor de MQTT entrega una alternativa al modelo tradicional de cliente y servidor; tradicionalmente el cliente se comunica directamente con el servidor, mientras en el modelo de publicador/suscriptor separa al cliente que envía el mensaje (publicador) del cliente o clientes que los reciben (suscriptores); jamás se contactan entre ellos, de hecho ni siquiera sabe si están ahí. Ya que la conexión entre ellos es manejada por una tercera parte (el bróker). El trabajo del bróker es filtrar los mensajes entrantes según las preferencias de cada suscriptor y posteriormente distribuirlos de manera correctas. Los mensajes pueden ser filtrados por tema, contenido y tipo.

Una de las ventajas de este modelo es que se da una separación del bróker y el cliente, esta separación se da a nivel de tiempo, es decir, no necesariamente están ejecutándose al mismo tiempo, de espacio porque no necesitan saber quiénes son y de sincronización que en ambos clientes la conexión no debe ser interrumpida.

MQTT: Conexión

El protocolo MQTT está basado en TCP/IP, los dos clientes y el bróker necesitan tener una pila TCP/IP. Hay que recordar que la conexión siempre es entre los clientes y el bróker, los clientes nunca se conectan entre ellos.

Para iniciar una conexión el cliente envía un mensaje de “conexión” al bróker y este responde con un mensaje de CONNACK (reconocimiento) y un código de estado; una vez se abre una conexión el bróker la mantiene abierta hasta que el cliente envía un mensaje de desconexión o hasta que la comunicación se rompa.

MQTT: Nivel de servicio

Existen tres niveles de servicio para garantizar la entrega de mensajes. El nivel “0” indica que el mensaje será recibido como máximo una vez, pero no hay una retroalimentación por parte del cliente que el mensaje fue recibido.

El nivel “1” garantiza que el mensaje será recibido al menos una vez por el suscriptor. El mensaje es guardado por la parte que envía hasta que recibe un paquete PUBACK del receptor confirmando que ya recibió el mensaje; en este nivel de servicio es posible que un mismo mensaje sea enviado y entregado varias veces.

El nivel de servicio “2” que indica que el suscriptor recibirá el mensaje exactamente una vez. Es el nivel de servicio más seguro pero más lento, ya que cada mensaje tiene que ser respaldo que ya fue recibido. En este nivel se garantiza que cada mensaje sea recibido exactamente una vez por el suscriptor por eso es tan lento.

MQTT: mensajes en cola

Para recibir mensajes de un bróker MQTT el cliente se conecta a este y crea suscripciones a diferentes temas. Si la conexión se interrumpe entre el cliente y el bróker durante una conexión no persistente, los mensajes de cualquier tema al que este suscrito el cliente se pierden y este se tiene que re suscribir al momento de volver a establecer la conexión con el bróker.

El tener que re suscribirse cada vez que la conexión se pierde puede ser algo desgastante para clientes que por su naturaleza cuentan con recursos muy limitados. Para evitar este problema el cliente puede solicitar una sesión persistente al momento de conectarse con el bróker. Este tipo de conexiones guardan la información relevante para determinado cliente en el bróker.

¿Qué información se guarda en su conexión persistente?

• La existencia de una sesión, aunque no existan suscriptores.
• Todos los suscriptores de un cliente
• Todos los mensajes para niveles de calidad de servicio 1 y 2 que el cliente aún no ha recibido.
• Todos los mensajes de nivel de calidad de servicio 1 y 2 que el cliente se perdió por estar fuera de línea.
• Todos los mensajes con calidad de servicio nivel 2 que el cliente no haya reconocido como recibidos de manera completa.

Toda la información antes mencionada es guardada por el bróker, aun cuando el cliente sale de línea. Cuando el cliente se reconecta la información está disponible de manera inmediata. Muchos se preguntarán cuanto tiempo guarda la información el bróker y la respuesta más sencilla es que la guarda, hasta que el cliente vuelve a estar en línea, pero si por alguna razón el cliente no se vuelve a conectar en un período de tiempo realmente largo; en estos casos la memoria del sistema operativo será la limitante principal al momento de guardar mensajes. No existe una respuesta general, todo dependerá de cada escenario.

MQTT: mensajes retenidos

Cuando un cliente publica un mensaje no tiene garantía que este llegue hasta los suscriptores, solo sabe que fue entregado de manera exitosa hasta el bróker. Lo mismo pasa con los suscriptores, no saben cuándo un cliente publicador enviará un mensaje nuevo, pueden pasar horas hasta que un cliente publicador envié un nuevo mensaje, durante todo ese tiempo los clientes suscriptores están a oscuras. Para evitar esto se pueden usar los mensajes retenidos.

El mensaje retenido no es más que el último mensaje válido para un determinado tema, que el bróker guarda, para que cuando cada nuevo cliente se suscriba recibirá este mensaje, para no estar a oscuras de cuando habrá una actualización de ese determinado tema. El bróker puede guardar solamente un mensaje por cada tema.

MQTT: última voluntad y testamento

Este tipo de mensaje es cuando un cliente publicador se desconecta de manera abrupta, si esto pasa el bróker sabrá qué hacer en este caso. Este mensaje es enviado por el publicador al bróker, para que este lo almacene y si el publicador se desconecta de manera abrupta, el bróker envía este mensaje a todos los suscriptores del tema de este publicador. Si el cliente publicador se desconecta de manera adecuada, el bróker descarta el mensaje de última voluntad.

Conclusión

Este protocolo es muy utilizado en aplicaciones de IoT, ya que su función de transmitir datos permite obtener telemetría de diferentes tipos de maquinarias y de esta manera poder determinar su desempeño a través del análisis de esta información. Además que elimina procesos engorrosos como tener que ir físicamente hasta donde está la maquinaria trabajando y obtener la data a través de dispositivos magnéticos para su posterior análisis.

Este protocolo cumple muy bien su función y se mantiene fiel a su enunciado de ser liviano, simple, fácil de implementar por parte del cliente y eficiente en la utilización de recursos.

Saludos a todos.-