en Desarrollo, Python

MQTT series I – Introducción al protocolo MQTT y el IoT

Introducción

MQ Telemetry Transport o también conocido como Message Queue Telemetry Transport, fue creado por Arlen Nipper y Andy Stanford-Clark en 1999 para el monitoreo de dispositivos, por medio de satélites. MQTT, por sus siglas en inglés, es un protocolo de comunicación M2M (machine to machine) que sigue el patrón PublishSubscribe, brindando la transferencia de mensajes con un consumo de recursos bajo.

En esta serie de blogs, dividida en dos partes, hablaremos acerca del protocolo MQTT y sus características, así como su relación con el IoT. Además, en la segunda parte realizaremos un caso práctico, creando una aplicación con tecnologías como Arduino, Python y NodeJS, para poner en práctica los conceptos abarcados en esta primera entrega.

El protocolo MQTT

MQTT está basado en el protocolo TCP lo que garantiza alta fiabilidad en el transporte de mensajes, evitando la pérdida de paquetes. Como se puede observar en la figura 1, en la estructura de red de MQTT, hay dos actores principales, los clientes y el message broker, donde los clientes pueden ser Publishers o Subscribers.

Fig 1. Actores en el protocolo MQTT.

El broker es el encargado de gestionar el flujo de mensajes, el publisher se encarga de publicar mensajes a un topic específico y el subscriber, se suscribe a uno o varios topics para recibir los mensajes que han sido publicados en ellos. Ahora bien, los topics son cadenas UTF-8 utilizadas por el broker para filtrar el flujo de mensajes, los publishers publican los mensajes en los topics y los subscribers que estén suscritos a él, recibirán el mensaje, por lo que la conexión siempre pasa por un intermediario que es el broker. Cabe destacar que MQTT soporta dos tipos de wildcards para los tópicos, + y #.

MQTT y el IoT

En el gran avance del Internet de las Cosas o, IoT por sus siglas en inglés, los sistemas de comunicación se han visto sumamente beneficiados por el protocolo MQTT, pues este brinda grandes capacidades para la transferencia de mensajes, consumiendo bajos recursos y poco ancho de banda. Utilizando la figura 2 como ejemplo, se muestra el uso de MQTT para un sistema IoT.

Fig 2. Sistema de IoT.

El edificio Klooid tiene cuatro departamentos lab, kitchen, lobby y bathroom, cada departamento tiene varios dispositivos que envían o reciben mensajes. La estructura de los topics para estos dispositivos es por niveles, donde cada nivel se separa con un ‘/‘. La definición de un tópico puede ser variada, sin embargo, el último nivel siempre indica el dispositivo al que se publica o se suscribe un cliente, en este ejemplo, la estructura utilizada: nivel_1/nivel_2/dispositivo. Algunos ejemplos son:

  • klooid/lab/temp: Dispositivo de temperatura del lab.
  • klooid/lab/smoke: Dispositivo de humo del lab.
  • klooid/bathroom/temp: Dispositivo de temperatura del bathroom.
  • klooid/lobby/temp: Dispositovo de temperatura del lobby.
  • klooid/lobby/cam: Dispositovo de la cámara del lobby.

La estructura de niveles en los topics facilita la categorización de los dispositivos para poder controlar el flujo de mensajes, pero, ¿qué pasa con los wildcards + y # que se habían mencionado? Estos son utilizados en la estructura de niveles de los topics, el wildcard # indica que de ese nivel en adelante, se van a contemplar todos los dispositivos disponibles. Por ejemplo, con klooid/lobby/#, se contempla:

  • klooid/lobby/smoke
  • klooid/lobby/temp
  • klooid/lobby/cam

Para klooid/#, se contemplan todos los topics, porque de ese nivel en adelante, están todos los niveles, lobby, lab, bathroom y kitchen, junto a los dispositivos para cada nivel, smoke, temp o cam.

Ahora bien, el wildcard ‘+’, se utiliza para designar que en un nivel específico, se deben contemplar todas las opciones, sin embargo, este sólo se puede utilizar intercalado en la definición del topic. Como ejemplo, se utiliza klooid/+/temp, esto indica que los dispositivos contemplados son:

  • klooid/lobby/temp
  • klooid/lab/temp
  • klooid/kitchen/temp
  • klooid/bathroom/temp

Así, se contempla únicamente el topic relacionado al dispositivo temp, pero para todos los departamentos. Por esta razón el wildcard +, se utiliza únicamente intercalado.

Características del protocolo MQTT

Ya hemos visto el funcionamiento del protocolo MQTT, sin embargo, este tiene características bastante interesantes que hacen de este protocolo, aún más atractivo. Estas características afectan tanto la conexión como la publicación, por lo que suelen ser útiles dependiendo de la aplicación a la que se encuentre la implementación.

QoS: Quality of Service

La primer característica que vamos a abarcar es la de Calidad de Servicio o QoS por sus siglas en inglés. QoS afecta directamente la conexión y la seguridad que se brinda para el envío de mensajes, hay tres tipos de QoS que se pueden configurar:

1. QoS 0

«At most once«, esta QoS asegura que se entregará el mensaje «a lo sumo, una vez», por lo que existe la posibilidad de que el mensaje no sea entregado. El mensaje se publica y la red se despreocupa del resultado de este envío. Es la QoS más ligera para la red y la que menor seguridad brinda.

2. QoS 1

«At least once«, esta QoS asegura que el mensaje será entregado «como mínimo, una vez», esto quiere decir que pueden producirse duplicados del mensaje. Cuando el mensaje se publica, entonces el cliente espera el PUBACK (acuse de recibido) desde el broker, si el PUBACK no es recibido, entonces el cliente vuelve a enviar el mensaje para asegurar el envío de este. Para esta QoS, podemos decir que se realiza una verificación de dos pasos, ahora bien, puede existir un problema con esta implementación, si el broker recibe el primer mensaje pero el PUBACK falla en la entrega, el cliente enviará un nuevo mensaje, lo que genera un duplicado.

3. QoS 2

«Exactly once«, esta QoS asegura «una única entrega» para el mensaje publicado. Para realizar este proceso, la interacción entre el cliente y el broker se realiza en cuatro pasos, primero el cliente publica el mensaje y espera por un PUBREC, el mensaje fue recibido, por lo que el publisher descarta el mensaje por medio de un PUBREL, cuando el broker recibe este mensaje, finaliza el proceso, respondiendo con un PUBCOMP para indicar que el proceso de publicación está completo. Esta es la QoS que genera mayor carga en la red, sin embargo, es la más segura.

Cabe destacar que MQTT trabaja sobre TCP, esto hace que la seguridad para la entrega de paquetes sea alta, por lo que en mucho casos un QoS 0 es más que suficiente, sin embargo, si la operación a realizar requiere seguridad mayor, se puede contemplar el uso de QoS 1 o QoS 2. Además, la QoS puede configurarse tanto para transferencia publisher-broker como para subscriber-broker, no obstante, la QoS de la sección subscriber-broker va a estar limitada por la QoS de la sección publisher-broker.

Clean Session

La segunda característica es la de Clean Session, la sesión limpia puede estar activada o desactivada en el momento en el que un subscriber se suscribe a un topic. En la figura 3 se puede observar lo que sucede para cuando está activado o desactivado.

Fig 3. Clean session para la gestión de mensajes.

Para cuando se realiza la conexión con la Clean Session activada, si el subscriber pierde la conexión, entonces todos los mensajes que hayan sido publicados a ese topic, no van a ser almacenados y cuando el subscriber se reconecta, habrá perdido estos mensajes. Caso contrario, si la Clean Session ha sido desactivada, entonces los mensajes serán almacenados y entregados al cliente, cuando este se reconecte.

Retained messages

La tercera característica se llama Retained Messages, los Retained Messages brindan la posibilidad de almacenar el último mensaje publicado a un topic específico y cuando un nuevo subscriber se conecte, este reciba el último mensaje enviado a ese topic. En la figura 4 se muestra un proceso de esta característica.

Fig 4. Aplicación de Retained Messages.

La diferencia con Clean Session es que en este caso, el mensaje guardado será el último y se actualizará con cada nuevo mensaje entrante, además de que esto es para todo los clientes nuevos, mientras que un Clean Session es para un cliente específico.

Last will and testament

La última pero no menos importante, la propiedad de «La ultima voluntad». Last will and testament o sólo Last will, es la única de las propiedades que veremos, que afecta la publicación y no la conexión. El publisher al realizar su conexión al broker, configura un mensaje en un topic, que contiene su Last will, si el publisher se desconecta, este mensaje será enviado a todos los subscribers que estén suscritos a ese topic. La figura 5 muestra el proceso de ejecución de la Last will.

Fig 5. Funcionamiento del Last Will and Testament.

Esto es útil para prevenir errores en el funcionamiento, datos corruptos u otra aplicación que se le pueda dar, evitando confusión en la información que está siendo procesada.

Conclusión

Se aclara el concepto de MQTT así como sus características, proporcionando un mejor panorama del porqué es tan distinguido en el campo del IoT, donde brinda grandes posibilidades para la gestión de de la comunicación de estos sistemas, debido a la las capacidad de aislamiento espacial y temporal, donde se evitan comunicación cliente a cliente, y se utiliza un broker para la transmisión de los mensajes.

Ya que tenemos claros los conceptos y características del protocolo MQTT y su relación con el IoT, en la próxima entrega realizaremos una aplicación con Python, NodeJS, Mosquitto y Arduino, para la implementación de este protocolo tan poderoso.

Escribe un comentario

Comentario