Contenido


Conociendo MQTT

¿Por qué MQTT es uno de los mejores protocolos de red para el Internet de las Cosas?

Comments

Para los dispositivos de Internet de las Cosas (IoT), la conexión a Internet es un requisito. La conexión a Internet permite que los dispositivos trabajen entre sí y con servicios de backend. El protocolo de red subyacente de Internet es el TCP/IP. Desarrollado con base en la pila TCP/IP, el MQTT (Message Queue Telemetry Transport) se ha convertido en el patrón para las comunicaciones del IoT.

Inicialmente, MQTT fue inventado y desarrollado por IBM a finales de los 90. Su aplicación original era vincular sensores en oleoductos de petróleo a satélites. Tal como sugiere su nombre, se trata de un protocolo de mensajería con soporte para la comunicación asíncrona entre las partes. Un protocolo de sistema de mensajes asíncrono separa al emisor y al receptor del mensaje tanto en el tiempo como en el espacio y, por lo tanto, es escalable en ambientes de red que no sean de confianza. Pese a su nombre, no tiene nada que ver con colas de mensajes; en realidad, utiliza un modelo de publicación y suscripción. A final de 2014, se convirtió oficialmente en un patrón abierto OASIS, con soporte en los lenguajes de programación populares, usando diversas implementaciones de software libre.

Por qué elegir MQTT

MQTT es un protocolo de red leve y flexible que ofrece el equilibrio ideal para los desarrolladores de IoT:

  • Un protocolo liviano permite la implementación en hardware de dispositivos altamente restringidos y en redes de ancho de banda limitada y de alta latencia.
  • Su flexibilidad hace posible el suporte a diversos escenarios de aplicación para dispositivos y servicios de IoT.

Para entender por qué el MQTT es tan adecuado para los desarrolladores de IoT, analizaremos la razón por la que otros protocolos de red populares han fallado en el IoT.

Por qué no usar alguno de los otros numerosos protocolos de red

La mayoría de los desarrolladores ya se acostumbró a los servicios de la Web HTTP. Así que, ¿por qué no conectar los dispositivos de IoT a los servicios web? El dispositivo podría enviar sus datos como una solicitud HTTP y recibir actualizaciones del sistema como una respuesta HTTP. Tal patrón de solicitud y respuesta tiene algunas graves limitaciones:

  • HTTP es un protocolo síncrono. El cliente espera a que el servidor responda. Los navegadores web tienen este requisito, pero el costo es la baja escalabilidad. En el mundo de IoT, la comunicación sincrónica ha sido un problema debido al gran número de dispositivos y a la red, a menudo no confiable y de alta latencia. Un protocolo de mensajería asíncrono es mucho más adecuado para aplicaciones de IoT. Los sensores pueden enviar lecturas y permitir que la red descubra el camino y la sincronización ideales para entregar a los dispositivos y servicios de destino.
  • HTTP es unidireccional. El cliente necesita iniciar la conexión. En un aplicativo de IoT, los dispositivos y sensores generalmente son clientes, lo que significa que no pueden recibir comandos de la red de forma pasiva.
  • HTTP es un protocolo de uno a uno. El cliente realiza una solicitud y el servidor responde. Es difícil y costoso transmitir un mensaje a todos los dispositivos en red, lo que es algo común en aplicaciones de IoT.
  • HTTP es un protocolo pesado con muchos encabezados y reglas. No es adecuado para redes restringidas.

Por todas estas razones, la mayoría de los sistemas escalables de alto rendimiento utilizan un bus de sistema de mensajes asíncrono, en vez de servicios web para el intercambio de datos internos. De hecho, el protocolo de sistema de mensajes más popular que se utiliza en sistemas de middleware corporativos se llama AMQP (Advanced Message Queuing Protocol). Sin embargo, en un entorno de alto rendimiento, la capacidad de cálculo y la latencia de la red no suelen ser una preocupación. El AMQP fue creado para asegurar la confiabilidad y la interoperabilidad en aplicaciones corporativas. Posee un buen conjunto en recursos, pero no es adecuado para aplicaciones de IoT con restricción de recursos.

Además del AMQP, existen otros protocolos populares de sistema de mensajes. Por ejemplo, XMPP (Extensible Messaging and Presence Protocol) es un protocolo de mensajería instantánea (IM) de punto a punto. Es pesado en recursos con soporte para casos de uso de IM, tales como presencia y archivos adjuntos audiovisuales. En comparación con MQTT, este exige mucho más recursos en el dispositivo y en la red.

Entonces, ¿cómo logra ser tan leve y flexible MQTT? Un recurso importante del protocolo MQTT es el modelo de publicación y suscripción. Como en todos los protocolos de sistema de mensajes, separa al editor y al consumidor de datos.

Modelo de publicación y de suscripción

El protocolo MQTT define dos tipos de entidades en la red: un bróker de mensajería y numerosos clientes. Bróker es un servidor que recibe todos los mensajes de los clientes y, en seguida, redirige estos mensajes a los clientes de destino relevantes. Un cliente es cualquier cosa que pueda interactuar con el bróker y recibir mensajes. Un cliente puede ser un sensor de IoT en campo o una aplicación en un centro de datos que procesa datos de IoT.

  1. El cliente se conecta al bróker. Puede suscribirse a cualquier "tema" de mensajería del bróker. Esta conexión puede ser una conexión TCP/IP simple o una conexión TLS cifrada para mensajes sensibles.
  2. El cliente publica los mensajes en un tema, enviando el mensaje y el tema al bróker.
  3. Después, el bróker remite el mensaje a todos los clientes que se suscriben a este tema.

Como los mensajes de MQTT se organizan por temas, el desarrollador de aplicaciones tiene la flexibilidad de especificar que determinados clientes solo pueden interactuar con determinados mensajes. Por ejemplo, los sensores publicarán sus lecturas en el tema "sensor_data" y se suscribirán al tema "config_change". Las aplicaciones de procesamiento de datos que guardan los datos del sensor en una base de datos de backend se suscribirán al tema "sensor_data". Una aplicación de consola administrativa podría recibir comandos del administrador del sistema para ajustar las configuraciones de los sensores, tales como la sensibilidad y la frecuencia de muestreo, y publicar dichos cambios en el tema "config_change". (Consulte Figura 1.)

Figura 1. El modelo de publicación y de suscripción de MQTT para sensores de IoT
Imagen de un diagrama de fluko que muestra mensajes de                     publicación y subscripción para la información de los sensores usando                     un bróker de MQTT, información de almacenamiento, y una consola de                     administrador
Imagen de un diagrama de fluko que muestra mensajes de publicación y subscripción para la información de los sensores usando un bróker de MQTT, información de almacenamiento, y una consola de administrador

Al mismo tiempo, MQTT es liviano. Tiene un encabezado simple para especificar el tipo de mensaje, un tema basado en texto y, posteriormente, una carga útil binaria arbitraria. La aplicación puede tener cualquier formato de datos para la carga útil, como JSON, XML, binario cifrado o Base64, siempre que los clientes de destino puedan analizar la carga útil.

Introducción al desarrollo con MQTT

La herramienta más fácil para empezar el desarrollo con MQTT es el módulo Python mosquitto, que forma parte del proyecto Eclipse Paho y proporciona SDKs y bibliotecas de MQTT en varios lenguajes de programación. Contiene un bróker de MQTT que puede ser ejecutado en la computadora local y herramientas de línea de comandos que pueden interactuar con el bróker usando mensajes. Es posible descargar e instalar el módulo mosquitto en elsitio web de mosquitto.

El comando mosquitto ejecuta el bróker de MQTT en la computadora local. Opcionalmente, es posible usar la opción -d para ejecutarlo en segundo plano.

$ mosquitto -d

Después, en otra ventana de la terminal, es posible usar el comando mosquitto_sub para conectarse al bróker local y suscribirse a un tema. Tras la ejecución del comando, esperará e imprimirá todos los mensajes que reciba de la suscripción a medida que estos lleguen.

$ mosquitto_sub -t "dw/demo"

En otra ventana de la terminal es posible usar el comando mosquitto_pub para conectarse al bróker local y, en seguida, publicar un mensaje en un tema.

$ mosquitto_pub -t "dw/demo" -m "hello world!"

En este momento, la terminal que ejecuta mosquitto_sub deberá exhibir "hello world!" en la pantalla. ¡Usted acaba de enviar y recibir un mensaje usando un bróker de MQTT!

Por supuesto que en un sistema de producción no es posible utilizar una computadora local como bróker. En ese caso, es posible usar el Servicio de la plataforma para Internet de las Cosas de IBM Cloud; un servicio bajo demanda y confiable que funciona como un bróker de MQTT. (Lea más acerca de cómo este servicio de IBM Cloud se integra y usa MQTT como su protocolo para comunicarse con dispositivos y aplicaciones en la documentación del servicio.)

O en el Servicio de la plataforma para Internet de las Cosas de IBM Cloud funciona de la siguiente forma.

  • En la consola de IBM Cloud, es posible crear, bajo demanda, una instancia del servicio de la plataforma para la Internet de las Cosas.
  • Á Continuación, es posible añadir dispositivos que puedan conectar la instancia de servicio utilizando el MQTT. Cada dispositivo tendrá un ID y un nombre. Solamente los dispositivos enumerados pueden acceder al servicio, y el papel de la plataforma Watson IoT relatará informaciones sobre tráfico y uso de estos servicios, en los correspondientes dispositivos.
  • Para cada cliente del dispositivo, IBM Cloud designará un nombre del host, un nombre de usuario y una contraseña para la conexión con una instancia de servicio (el bróker de MQTT). (En IBM Cloud, el nombre de usuario siempre es use-token-auth y la contraseña es el token que se muestra en Figura 2 para cada dispositivo conectado).
Figura 2. Creando una instancia de servicio de la plataforma para el Internet de las Cosas en IBM Cloud
Credenciales de su dispositivo
Credenciales de su dispositivo

Al usar un bróker remoto del MQTT, será necesario obtener la aprobación de las credenciales de autenticación y de nombre del host del bróker para los comandos mosquitto_sub y mosquitto_pub. Por ejemplo, el siguiente comando se suscribe al tema de demonstración de nuestro servicio de plataforma para Internet de las Cosas con el nombre de usuario y contraseña proporcionados por IBM Cloud:

$ mosquitto_sub -t "demo" -h host.iotp.mqtt.bluemix.com -u nombre de usuario -P contraseña

Para conocer más opciones sobre cómo usar las herramientas de mosquitto y la API de mosquitto para crear sus propias aplicaciones clientes del MQTT, consulte la documentación en el sitio web de mosquitto.

Ahora que ya tiene las herramientas necesarias, investiguemos más profundamente el protocolo MQTT.

Comprendiendo el protocolo MQTT

MQTT es un protocolo de conexión que explica cómo los bytes de datos son organizados y transmitidos por la red TCP/IP. Pero, por razones prácticas, los desarrolladores no necesitan comprender el protocolo de enlace. Basta con saber que cada mensaje tiene una carga útil de comando y datos. El comando define el tipo de mensaje (por ejemplo, un mensaje CONNECT o un mensaje SUBSCRIBE). Todas las bibliotecas y herramientas de MQTT ofrecen maneras sencillas de manipular directamente tales mensajes y pueden completar algunos campos necesarios automáticamente, como los IDs del mensaje y del cliente.

Primeramente, el cliente se conecta al bróker enviando un mensaje CONNECT. El mensaje CONNECT pide para que se establezca una conexión entre el cliente y el bróker. El mensaje CONNECT contiene los siguientes parámetros de contenido.

Tabla 1. Parámetros del mensaje CONNECT
ParámetroDescripción
cleanSession Esta señalización dice si la conexión es persistente o no. Una sesión persistente almacena todas las suscripciones y los mensajes posiblemente perdidos (dependiendo del QoS) en el bróker. (Consulte Tabla 3 para obtener una descripción de la QoS).
nombre de usuario Las credenciales de autenticación y autorización del bróker.
contraseña Las credenciales de autenticación y autorización del bróker.
lastWillTopic Cuando la conexión se cae inesperadamente, el bróker automáticamente publicará en un tema un mensaje de "último deseo".
lastWillQos La QoS del mensaje de "último deseo". (Consulte Tabla 3 para obtener una descripción de la QoS).
lastWillMessage El mensaje en sí de "último deseo".
keepAlive Este es el intervalo de en el que el cliente necesita realizar un ping en el bróker para mantener activa la conexión.

El cliente recibirá un mensaje CONNACK del bróker. El mensaje CONNACK contiene los siguientes parámetros de contenido.

Tabla 2. Parámetros del mensaje CONNACK
ParámetroDescripción
sessionPresent Indica si la conexión ya contiene una sesión persistente. O sea, la conexión ya contiene temas suscritos y recibirá la entrega de mensajes ausentes.
returnCode 0 indica éxito. Otros valores identifican la causa de la falla.

Una vez establecida la conexión, el cliente podrá enviar uno o más mensajes SUBSCRIBE al bróker para indicar que recibirá mensajes de determinados temas del bróker. El mensaje puede tener una o varias repeticiones de los siguientes parámetros

Tabla 3. Parámetros del mensaje SUBSCRIBE
ParámetroDescripción
qos La señalización qos (calidad de servicio o QoS) indica con qué consistencia los mensajes, en este tema, necesitan ser entregados a los clientes.
  • Valor 0: no confiable, el mensaje es entregado como máximo una sola vez; en caso de que el cliente no se encuentre disponible en este momento, perderá el mensaje.
  • Valor 1: el mensaje se debe entregar al menos una vez.
  • Valor 2: el mensaje se debe entregar exactamente una vez.
tema Puede suscribirse a un tema. Un tema puede contener varios niveles separados por caracteres de barra. Por ejemplo, "dw/demo" y "ibm/bluemix/mqtt" son temas válidos.

Después de que el cliente se haya suscrito a un tema con éxito, el bróker retornará un mensaje SUBACK con uno o más parámetros returnCode.

Tabla 4. Parámetros del mensaje SUBACK
ParámetroDescripción
returnCode Existe un código de retorno para cada uno de los temas en el comando SUBSCRIBE. Los valores de retorno son los siguientes.
  • Valores 0 a 2: éxito como nivel de QoS correspondiente. (Consulte Tabla 3 para saber más sobre la QoS.)
  • Valor 128: falla.

Según el mensaje SUBSCRIBE, el cliente también podrá UNSUBSCRIBE (cancelar la suscripción) de uno o varios temas.

Tabla 5. Parámetros del mensaje UNSUBSCRIBE
ParámetroDescripción
tema Este parámetro puede repetirse en varios temas.

El cliente puede enviar mensajes PUBLISH al bróker. El mensaje contiene un tema y una carga útil de datos. Después, el bróker remite el mensaje a todos los clientes que se suscriben a este tema.

Tabla 6. Parámetros del mensaje PUBLISH
ParámetroDescripción
topicName El tema en el cual se publica el mensaje.
qos El nivel de calidad de servicio de la entrega del mensaje. (Consulte Tabla 3 para obtener una descripción de la QoS).
retainFlag Esta señalización indica si el bróker retendrá el mensaje como el último mensaje conocido de este tema.
carga útil Los datos reales en el mensaje. Puede ser una secuencia de texto o un blob binario de datos.

Consejos y soluciones alternativas

El poder de MQTT es su simplicidad. No existen restricciones con relación al tipo de tema o de carga útil de mensaje que se puede usar. Eso permite algunos casos de uso interesantes. Por ejemplo, considere estas cuestiones:

¿Cómo ejecutar mensajes de uno a uno con MQTT? Ambas partes pueden ponerse de acuerdo en usar un tema que sea exclusivo para estas. Por ejemplo, el nombre del tema puede contener los IDs de los dos clientes para garantizar su exclusividad.

¿Cómo un cliente transmite su status de presencia? El sistema puede ponerse de acuerdo con una convención de nomenclatura para temas de "presencia". Por ejemplo, el tema "presence/client-id" puede contener la información de presencia del cliente. El cliente define el mensaje como "true" cuando se conecta y "false" cuando se desconecta. El cliente también puede configurar un mensaje de "last will" como "false" para ser definida cuando la conexión se caiga. El bróker puede retener el mensaje para que nuevos clientes puedan leer el tema y descubrir el estatus de presencia.

¿Cómo proteger las comunicaciones? La conexión del cliente con el bróker puede ser una conexión TLS cifrada para proteger los datos en tránsito. Además, como el protocolo MQTT no impone restricciones con relación al formato de datos de la carga útil, el sistema puede concordar con un método de cifrado y un mecanismo de actualización de claves. Posteriormente, todo el contenido en la carga útil puede ser de datos binarios cifrados de los mensajes JSON o XML reales.

Conclusión

En este artículo, proporcioné una presentación técnica acerca del protocolo MQTT. Ha aprendido lo que es MQTT, por qué es adecuado para aplicaciones que usan IoT y cómo empezar a desarrollar aplicaciones que usan MQTT.

En uno de mis próximos artículos, mostraré cómo desarrollar una solución completa de sensor de IoT con servicios del MQTT de backend y usando una placa NodeMCU.

Recursos


Recursos para Descargar


Temas relacionados


Comentarios

Inicie Sesión o Regístrese para agregar comentarios.

static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=90
Zone=Internet of Things
ArticleID=1050600
ArticleTitle=Conociendo MQTT
publish-date=12052018