Conozca MQTT – IBM Developer

Conozca MQTT

Para dispositivos de Internet de las Cosas (IoT) es necesaria la conexión a Internet. La conexión a Internet permite que los dispositivos trabajen entre ellos y con servicios backend. El protocolo de red subyacente de internet es TCP/IP. MQTT (Message Queue Telemetry Transport), que está construido sobre la pila de TCP/IP, se ha convertido en el estándar para las comunicaciones de IoT.

Originariamente, MQTT fue inventado y desarrollado por IBM a finales de los 90. Su aplicación original era conectar sensores de los oleoductos con satélites. Tal como sugiere su nombre, es un protocolo de mensajería que soporta la comunicación asíncrona entre las partes. Un protocolo de mensajería asíncrona disocia al emisor y al receptor de los mensajes tanto en espacio como en tiempo, y, por lo tanto, es escalable en entornos de red no confiables. A pesar de su nombre, no tiene nada que ver con las colas de mensajería, y, en cambio, utiliza un modelo de publicación y suscripción. A finales del 2014, se convirtió oficialmente en un estándar abierto de OASIS, y se soporta en lenguajes de programación populares mediante la utilización de varias implementaciones de código abierto.

Por qué MQTT

MQTT es un protocolo de red liviano y flexible que logra el equilibrio adecuado para los desarrolladores de IoT:

  • El protocolo liviano le permite implementarse en hardware de dispositivos altamente limitados y en redes con ancho de banda de alta latencia/limitado.
  • Su flexibilidad hace que pueda soportar varios escenarios de aplicaciones para dispositivos y servicios de IoT.

Para entender por qué MQTT es tan adecuado para los desarrolladores de IoT, examinemos porqué otros protocolos de red populares han fallado con IoT.

Por qué no… el resto de la sopa de letras de los protocolos de red

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

  • HTTP es un protocolo sincronizado. El cliente espera a que el servidor responda. Los navegadores web tienen este requisito, que trae consigo el costo de una mala escalabilidad. En el mundo de IoT, el gran número de dispositivos y muy probablemente una red no confiable, o de alta latencia, han hecho que la comunicación sincronizada sea problemática. Un protocolo de mensajería asíncrona es mucho más adecuado para las aplicaciones de IoT. Los sensores pueden enviar lecturas y dejar que la red descubra la ruta y el momento óptimos para la entrega de dispositivos y servicios de destino.
  • El HTTP tiene una dirección. El cliente debe iniciar una conexión. En una aplicación de IoT los dispositivos y los sensores son normalmente los clientes, lo que significa que no pueden recibir comandos de la red de forma pasiva.
  • HTTP es un protocolo 1-1. El cliente hace una solicitud y el servidor responde. Transmitir un mensaje a todos los dispositivos de la red, lo que es un caso de uso habitual en las aplicaciones IoT, es algo difícil y caro.
  • HTTP es un protocolo pesado con muchas cabeceras y reglas. No es adecuado para redes congestionadas.

Por las razones anteriores, la mayor parte de los sistemas escalables de alto rendimiento utilizan un bus de mensajería asíncrona, en vez de servicios web, para intercambiar datos internamente. De hecho, el protocolo de mensajería que se utiliza más habitualmente en los sistemas de middleware empresarial se llama AMQP (Advanced Message Queuing Protocol). Sin embargo, en entornos de alto rendimiento, el poder de la computación y la latencia de la red no son generalmente una preocupación. AMQP está diseñado para la confiabilidad y la interoperabilidad en aplicaciones empresariales. Tiene un amplio conjunto de funciones, pero no es adecuado para aplicaciones de IoT con recursos limitados.

Además de AMQP, hay otros protocolos de mensajería populares. Por ejemplo, el XMPP (Extensible Messaging and Presence Protocol) es un protocolo de mensajería instantánea (IM) peer-to-peer. Tiene muchas funciones que soportan casos de uso de IM, como los adjuntos de presencia y de medios de comunicación. Comparado con MQTT, requiere muchos más recursos tanto en el dispositivo como en la red.

Así que, ¿qué es lo que hace que MQTT sea tan liviano y flexible? Una de las principales funciones del protocolo MQTT es su modelo de publicación y suscripción. Como con todos los protocolos de mensajería, éste desacopla los datos del consumidor y del publicador.

El modelo de publicación y suscripción

El protocolo MQTT define los tipos de entidades en la red: un intermediario de mensajes y un número de clientes. El intermediario es un servidor que recibe todos los mensajes de los clientes y luego los redirige a clientes de destinos relevantes. Un cliente es cualquier cosa que pueda interactuar con el intermediario para enviar y recibir mensajes. Un cliente puede ser un sensor de IoT en el campo o una aplicación del centro de datos que procesa datos de IoT.

  1. El cliente se conecta con el intermediario. Se puede suscribir a cualquier «tema» de mensajes de intermediario. Esta conexión puede ser una conexión TCP/IP simple o una conexión TLS cifrada para mensajes confidenciales.
  2. El cliente publica el mensaje, sobre un tema, enviando el mensaje y el tema al intermediario.
  3. Después, el intermediario redirige el mensaje a todos los clientes que están suscritos a ese tema.

Ya que los mensajes MQTT están organizados por temas, el desarrollador de aplicaciones tiene la flexibilidad de especificar que ciertos clientes solo puedan interactuar con determinados mensajes. Por ejemplo, los sensores publicarán sus lecturas sobre del tema «sensor_data» y se suscribirán al tema «config_change». Las aplicaciones de procesamiento de datos que guardan datos del sensor en una base de datos backend se suscribirán al tema «sensor_data». Una aplicación de consola de administración puede recibir los comandos del administrador del sistema para ajustar las configuraciones de los sensores, como la sensibilidad y la frecuencia de la muestra, y publicar esos cambios en el tema «config_change». (Vea El modelo de publicación y suscripción de MQTT para los sensores de IoT.)

El modelo de publicación y suscripción de MQTT para los sensores de IoT

Imagen del diagrama de flujo que muestra mensajes de publicación y suscripción de datos del sensor utilizando un bróker MQTT, almacenamiento de datos y una consola de administración

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

Cómo iniciar con el desarrollo de MQTT

La herramienta más sencilla para iniciar con el desarrollo de MQTT es el módulo mosquitto de Python, que forma parte del proyecto Eclipse Paho que brinda SDKs y bibliotecas de MQTT en varios lenguajes de programación. Contiene un intermediario de MQTT que se puede ejecutar en su computadora local, y herramientas de línea de comando para interactuar con el intermediario mediante la utilización de mensajes. Es posible descargar e instalar el módulo de mosquitto desde el website de mosquitto.

El comando de mosquitto ejecuta el intermediario de MQTT en su computadora local. Opcionalmente, es posible utilizar la opción -d para ejecutarlo en un segundo plano.

$ mosquitto -d

Después, es posible utilizar el comando mosquitto_sub en otra ventana terminal para conectar el intermediario local y suscribirse a un tema. Después de que se ejecute el comando, esperará e imprimirá cualquier mensaje que reciba de la suscripción según llega.

$ mosquitto_sub -t "dw/demo"

Es posible utilizar el comando mosquitto_pub en otra ventana terminal para conectar el intermediario local y después de publicar un mensaje en un tema.

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

Ahora, el terminal que ejecuta mosquitto_sub debería imprimir «hello world!» en la pantalla. ¡Acaba de enviar y recibir un mensaje utilizando un intermediario de MQTT!

Por supuesto, en un entorno de producción no puede utilizar su computadora local como su intermediario. En vez de eso, puede utilizar el servicio IBM Cloud Internet of Things Platform, que es un servicio confiable y bajo demanda que funciona como un intermediario de MQTT. (Es posible leer más acerca de cómo este servicio de IBM Cloud integra y utiliza MQTT como su protocolo de comunicación con dispositivos y aplicaciones en la documentación del servicio.)

La IBM Cloud Internet of Things Platform funciona de la siguiente manera.

  • Desde la consola de IBM Cloud usted puede crear una instancia bajo demanda del servicio Internet of Things Platform.
  • A continuación, es posible añadir dispositivos que conecten la instancia del servicio utilizando MQTT. Cada dispositivo tendrá un ID y un nombre. Solo los dispositivos de la lista pueden acceder al servicio, y el panel de instrumentos de Watson IoT Platform informará sobre el tráfico y la utilización de esos dispositivos.
  • IBM Cloud asignará un nombre de host, un nombre de usuario y una contraseña para conectarse a la instancia de su servicio (el intermediario de MQTT). (En IBM Cloud, el nombre de usuario siempre es use-token-auth, y la contraseña es el token que se muestra Crear una instancia del servicio Internet of Things Platform en IBM Cloud para cada dispositivo conectado.)
Crear una instancia del servicio Internet of Things Platform en IBM Cloud

Ventana que muestra la información del dispositivo registrado

Cuando se utiliza un intermediario MQTT remoto es necesario pasar el nombre de host PRI y las credenciales de autenticación del intermediario para sus comandos de mosquitto_sub y mosquitto_pub. Por ejemplo, el siguiente comando suscribe al tema de demo sobre nuestro servicio de Internet of Things Platform con el nombre de usuario y la contraseña que IBM Cloud brinda:

$ mosquitto_sub -t "demo" -h host.iotp.mqtt.bluemix.com -u username -P password

Para más opciones sobre cómo utilizar las herramientas de mosquitto y también para saber cómo utilizar la API de mosquitto para crear sus propias aplicaciones del cliente MQTT, vea la documentación del sitio web de mosquitto.

Ahora que tiene las herramientas necesarias, entremos más a fondo en el protocolo de MQTT.

Cómo entender el protocolo de MQTT

MQTT es un protocolo de cable que especifica cómo se organizan los bytes de datos y cómo se transmiten a través de la red TCP/IP. Pero para propósitos prácticos, los desarrolladores no necesitan entender el protocolo de cable. Todo lo que necesitan saber es que cada mensaje tiene un comando y una carga útil de datos. El comando define el tipo de mensaje (por ejemplo: un mensaje CONNECT o un mensaje SUBSCRIBE). Todas las bibliotecas y herramientas de MQTT brindan formas sencillas de manipular directamente esos mensajes y pueden rellenar automáticamente algunos campos obligatorios, como los IDs del mensaje y del cliente.

Primero, el cliente se conecta con el intermediario enviando un mensaje CONNECT. El mensaje CONNECT pide establecer una conexión desde el cliente hacia el intermediario. El mensaje CONNECT tiene los siguientes parámetros de contenido.

Parámetros del mensaje CONNECT {: #parámetros-del-mensaje-connect}

Parámetro Descripción cleanSession Este identificador especifica si la conexión es persistente o no. Una sesión persistente almacena todos los mensajes de la suscripción y los que potencialmente se han perdido (dependiendo de QoS) en el intermediario. (Vea Parámetros del mensaje SUBSCRIBE para obtener una descripción de QoS.)nombre de usuario La autenticación del intermediario y las credenciales de autorización.contraseña La autenticación del intermediario y las credenciales de autorización.lastWillTopic Cuando una conexión se cae de forma inesperada, el intermediario publica automáticamente un mensaje de «última voluntad» en un tema.lastWillQos El mensaje de «última voluntad» en QoS. (Vea Parámetros del mensaje SUBSCRIBE para obtener una descripción de QoS.)lastWillMessage El propio mensaje de «última voluntad».keepAlive Este es el intervalo de tiempo para que el cliente compruebe la disponibilidad del intermediario para mantener la conexión viva.

El cliente recibirá un mensaje CONNACK del intermediario. El mensaje CONNACK tiene los siguientes parámetros de contenido.

Parámetros del mensaje CONNACK {: #parámetros-del-mensaje-connack}

Parámetro Descripción sessionPresent Esto indica si la conexión ya tiene una sesión persistente. Esto significa que la conexión ya tiene temas a los que se ha suscrito, y que recibirá la entrega de los mensajes que faltan.returnCode0 indica éxito. Otros valores identifican la causa de la falla.

Después de que se establece una conexión, el cliente puede enviar al intermediario uno o más mensajes SUBSCRIBE para indicar que recibirá mensajes del intermediario para determinados los temas. Esos mensajes pueden tener una o varias repeticiones de los siguientes parámetros.

Parámetros del mensaje SUBSCRIBE {: #parámetros-del-mensaje-subscribe}

Parámetro Descripción qos El indicador qos (calidad de servicio, o QoS) indica la consistencia con la que los mensajes de este tema se tienen que entregar a los clientes.

  • Valor 0: No confiable, el mensaje se entrega como mucho una vez, si el cliente no está disponible en ese momento se perderá el mensaje.
  • Valor 1: el mensaje se debería entregar al menos una vez.
  • Valor 2: el mensaje se debería entregar exactamente una vez.

temaUn tema al que suscribirse. Un tema puede tener varios niveles separados por el carácter de barra diagonal. Por ejemplo: «dw/demo» y «ibm/bluemix/mqtt» son temas válidos.

Después de que un cliente se haya suscrito correctamente a un tema, el intermediario devuelve un mensaje SUBACK con uno o más parámetros «returnCode».

Parámetros del mensaje SUBACK {: #parámetros-del-mensaje-suback}

Parámetro Descripción returnCode En el comando SUBCRIBE existe un código de retorno para cada uno de los temas. Los valores de retorno son los siguientes.

Corresponde al mensaje SUBSCRIBE, también puede dejar la suscripción (UNSUBSCRIBE) de un tema o de varios.

Parámetros del mensaje UNSUBSCRIBE {: #parámetros-del-mensaje-unsubscribe}

Parámetro Descripción tema Este parámetro se puede repetir para varios temas.

El cliente puede enviar mensajes PUBLISH al intermediario. El mensaje contiene un tema y una carga útil de datos. Después, el intermediario redirige el mensaje a todos los clientes que están suscritos a ese tema.

Parámetros del mensaje PUBLISH {: #parámetros-del-mensaje-publish}

Parámetro Descripción topicName El tema en que se publica el mensaje.qos La calidad del nivel de servicio de la entrega del mensaje. (Vea Parámetros del mensaje SUBSCRIBE para obtener una descripción de QoS.)retainFlag Este indicador indica si el intermediario retendrá el mensaje como el último mensaje conocido para este tema.carga útil Los datos reales que hay en el mensaje. Puede ser una cadena de texto o una bola binaria de datos.

Consejos y soluciones alternativas

Su simplicidad es el poder de MQTT. No hay limitaciones para el tipo de temas o cargas de trabajo de mensajes que puede utilizar. Esto permite algunos casos de uso interesantes. Por ejemplo, considere estas preguntas:

¿Cómo creo mensajes 1-1 con MQTT? Ambas partes pueden estar de acuerdo para utilizar un tema único para ellas. Por ejemplo: para garantizar su singularidad, el nombre del tema puede contener los IDs de ambos clientes.

¿Cómo hace un cliente para trasmitir el estado de su presencia? El sistema puede tener una convención de nomenclatura acordada para los temas de «presencia». Por ejemplo: el tema «presence/client-id» podría tener la información de la presencia de un cliente. El cliente configura el mensaje a verdadero cuando se conecta, y a falso cuando se desconecta. El cliente también puede establecer un mensaje de la última voluntad a falso, para que se establezca eso cuando la conexión se caiga. El intermediario puede retener el mensaje para que los clientes nuevos puedan leer el tema y descubrir el estado de la presencia.

¿Cómo protejo las comunicaciones? La conexión del cliente al intermediario puede ser una conexión TLS cifrada para proteger los datos que se transmiten. Además, ya que el protocolo MQTT no impone limitaciones en el formato de los datos de la carga útil, el sistema podría tener un método de cifrado acordado y un mecanismo de actualización de claves. Después de todo, todo el contenido de la carga útil podrían ser datos binarios cifrados de los mensajes JSON o XML.

Conclusión

En este artículo, he proporcionado una introducción técnica para el protocolo MQTT. Usted ha aprendido qué es MQTT, qué hace de MQTT adecuado para aplicaciones de IoT, y cómo iniciar con aplicaciones de desarrollo que utilizan MQTT.

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

Aviso

El contenido aquí presentado fue traducido de la página IBM Developer US. Puede revisar el contenido original en este link.