Vamos a comenzar a adentrarnos en el apasionante mundo del Internet de las cosas (IoT) y empezamos viendo los protocolos de comunicación disponibles para aplicaciones de IoT.
Como sabemos el IoT es un campo en auge que, en forma muy resumida, consiste en que una gran cantidad de objetos cotidianos están o van a estar conectados entre sí.
El IoT está de moda, de esto no cabe duda. Aunque hay mucho “humo” en torno al IoT, como siempre pasa en todos los temas de moda, lo cierto es que previsiblemente ha llegado para quedarse.
Parte del auge del IoT es la popularidad de Internet y los Smartphone, la mejora de los sistemas de comunicación, y la aparición de dispositivos con conectividad pequeños, baratos y de bajo consumo como el ESP8266 o el ESP32.
Como hemos visto en la definición, la comunicación entre dispositivos es la piedra central del IoT. Por tanto, empezaremos viendo algunos protocolos de comunicación existentes en el ámbito del IoT.
Si pensamos en estos protocolos de IoT seguramente nos vendrá a la cabeza rápidamente el popular MQTT. Sin embargo, no sólo existe todo es MQTT en el campo del IoT. En esta entrada veremos distintos protocolos, algunas de sus características, y la motivación de su existencia.
En la siguiente entrada de la serie de IoT nos centraremos en el MQTT, que como hemos dicho es uno de los protocolos más habituales y accesibles en nuestros proyectos maker.
¿Por qué un protocolo para IoT?
Un protocolo de comunicación es una serie de normas que definimos para que dos o más dispositivos puedan comunicarse y entenderse.
Como sabremos, tenemos muchas formas de comunicar realizar la comunicación M2M (machine-to-machine). Actualmente, con el desarrollo que han tenido las telecomunicaciones y el impulso que ha supuesto Internet, esto no resulta ningún problema.
Sin embargo, en el campo del IoT tenemos ciertos requisitos especiales que hacen que las habituales formas de comunicación entre dispositivos no sean totalmente adecuados ¿Cuáles son estos condicionantes?
Condicionantes del M2M en IoT
En primer lugar, en el IoT tenemos (o podemos llegar a tener) una gran cantidad de dispositivos. Algunos de ellos serán pequeños (de pequeños recursos), como sensores o actuadores. Mientras que otros serán más grandes, como un servidor que recoge información, almacena datos, y procesa estadísticas.
Otro requisito es que queremos que sea escalable, es decir, que puedan añadirse o retirarse dinámicamente dispositivos sin que el comportamiento global del sistema se modifique.
También es importante mantener débil el acoplamiento entre dispositivos. Es decir, queremos que la dependencia entre los dispositivos sea la menor posible, y deseablemente nula.
Otro requisito es que algunos de los dispositivos serán dispositivos embebidos, con bajo coste y escasa capacidad de cálculo. Por tanto, tiene que ser un protocolo que requiera poca capacidad de procesado.
Relacionado con la variedad y número de dispositivos, vamos a querer interoperabilidad. Es decir, que nuestra solución funcione la mayor variedad de dispositivos, sistemas operativos, y lenguajes de programación.
Además, es posible que haya un gran número de comunicaciones simultáneas y, en general, se requiere una respuesta rápida. Esto requiere que los mensajes transmitidos sean pequeños y, nuevamente, no requieran un gran procesamiento.
Por supuesto, tenemos siempre presente el condicionante de la seguridad, ya que estos dispositivos están expuestos a Internet (que no es un lugar nada seguro) y transmiten información privada e incluso controlan sistemas físicos.
Finalmente, tenemos que poder acceder a los dispositivos fácilmente, por lo que tendremos que lidiar con direcciones dinámicas y DHCP, posibles conexiones con mala latencia o ancho de banda, dependencia con la infraestructura de la red, firewalls, etc.
Soluciones de comunicación en el IoT
Entonces ¿cómo conseguimos que un número de dispositivos, distribuidos en ubicaciones y redes desconocidas, se comuniquen entre ellos de forma fiable y escalable?
Una posible solución, que está siendo ampliamente empleada, es externalizar la comunicación un servicio de notificaciones centralizado. De hecho, es una infraestructura cada vez más habitual en informática, tanto en aplicaciones de IoT como las que no.
En definitiva, la solución consiste en disponer un servidor central que se encarga de recibir los mensajes de todos los dispositivos emisores, y distribuirlos a los receptores. De forma genérica llamaremos a este servidor ‘Router’ o ‘Broker’.
Puede parecer un poco extraño disponer de un servidor encargado únicamente de distribuir mensajes. Pero en realidad, llevamos años usando soluciones parecidas. Sin ir más lejos, un cartero es un servicio externo encargado de distribuir mensajes.
Este servidor, tiene una dirección fija (o equivalentemente un dominio), de forma que es accesible por todos los dispositivos, con lo que resolvemos el problema de tener que encontrar al otro dispositivo.
El servidor mantiene un registro de los dispositivos conectados, recibe los mensajes, y los distribuye al resto dispositivos, filtrando los destinatarios según algún criterio.
Los dispositivos en ningún momento ‘ven’ o dependen del resto de dispositivos. Por tanto, esta infraestructura nos proporciona la escalabilidad.
Metodologías en IoT
Vamos a repasar un par de términos en cuanto a metodologías que podemos encontrar en IoT. En realidad, los conceptos son parecidos, pero conviene entender las diferencias (aunque sólo sea para hablar con propiedad).
Publish / Susbcribe (PubSub)
La metodología Pub/Sub es un patrón de mensajería donde un agente, el ‘Subscriber’, informa al Router que quiere recibir un tipo de mensajes. Otro agente, el ‘Publisher’ puede publicar mensajes. El Router distribuye los mensajes a los Subscribers.
Router Remoder Procedure Calls (rRPC)
El rRPC es un patrón de ejecución remota de procedimientos donde un agente, llamado ‘Callee’, comunica al Router que proporciona un cierto procedimiento. Otro agente, llamado ‘Caller’, puede llamar a este procedimiento. El Router invoca el procedimiento en el Callee, recoge el resultado del proceso, y lo comunica al Caller que lo ha invocado.
Infraestructuras de servicios en IoT
Existen varias aproximaciones para realizar un patrón PubSub o rRPC. Vamos a ver dos de las principales. A efectos prácticos, podemos conseguir funcionalidades similares en ambos planteamientos, pero igual que en el caso anterior conviene ser consciente de la diferencia.
No obstante, también hay que destacar que existen soluciones que adoptan un comportamiento intermedio o híbrido entre ambos planteamientos.
Message queue
En un servicio de mensajería de tipo Message Queue el Router genera una cola de mensajes única para cada uno de los clientes que inician la subscripción. El Router discrimina los mensajes empleando el identificador del cliente, aunque por supuesto existen mecanismos para distribuir a múltiples clientes.
Estas colas de mensajes de cliente mantienen los mensajes recibidos hasta que son entregados al cliente. De forma que si se recibe un mensaje cuando el cliente no está conectado, se mantienen en el Router y son entregados cuando se conecta.
Un ejemplo de Message Queue es una aplicación de mensajería tipo Whastapp o Telegram, donde el usuario recibe los mensajes que ha recibido mientras no estaba conectado. Otro ejemplo cotidiano es el buzón de correo de tu casa. Si estás fuera de vacaciones, cuando vuelves tienes todos tus mensajes esperándote.
Message Service
Otro planteamiento es servicio de mensajería puro o Message Service. En este caso, el router distribuye inmediatamente los mensajes a los clientes conectados. Los mensajes se filtran por algún criterio, como el tema o el contenido del mensaje.
A diferencia de un Message Queue, los mensajes entregados mientras el cliente está desconectado se pierden. No obstante, eso no significa que un servicio Message Service no pueda implementar algún tipo de persistencia de datos, por ejemplo, para analítica, históricos, o calidad del servicio.
Un ejemplo de Message Services es un chat, donde no podemos recuperar los mensajes emitidos cuando no estábamos en la sala. Otro ejemplo cotidiano es una conversación a viva voz. Si alguien dice algo mientras estamos en otra habitación, aunque entremos nos hemos perdido lo que se dijo antes.
Protocolos para IoT
Ahora que hemos visto la necesidad y planteamiento de los protocolos destinados a aplicaciones de IoT, vamos a ver algunos de los muchos protocolos M2M disponibles.
- MQTT (MQ Telemetry Transport) es un protocolo PubSub de Message Service que actúa sobre TCP. Destaca por ser ligero, sencillo de implementar. Resulta apropiado para dispositivos de baja potencia como los que frecuentemente tenemos en IoT. Está optimizado para el routing activo de un gran número de clientes conectados de forma simultánea.
- AMQP (Advanced Message Queuing Protocol) es un protocolo PubSub de Message Queue. AMQP está diseñado para asegurar la confiabilidad e interoperabilidad. Está pensado para aplicaciones corporativas, con mayor rendimiento y redes de baja latencia. No resulta tan adecuado para aplicaciones de IoT con dispositivos de bajos recursos.
- WAMP (Web Application Messaging Protocol) es un protocolo abierto que se ejecuta sobre WebSockets, y provee tanto aplicaciones de PubSub como rRPC.
- CoAP (Constrained Application Protocol) es un protocolo pensado para emplearse en dispositivos de IoT de baja capacidad. Emplea el modelo REST de HTTP con cabeceras reducidas, añadiendo soporte UDP, multicast, y mecanismos de seguridad adicionales.
- STOMP (Streaming Text Oriented Messaging Protocol, es un protocolo sencillo que emplea HTTP y mensajes de texto para buscar el máximo de interoperabilidad.
- XMPP (Extensible Messaging and Presence Protocol) es un protocolo abierto basado en XML diseñado para aplicaciones de mensajería instantánea.
- WMQ (WebSphere MQ) es un protocolo de Message Queue desarrolado por IMB.
Hasta aquí esta entrada sobre protocolos de comunicación M2M en IoT. Hemos visto las necesidades especiales de estos protocolos y cómo resolverlo con una externalización en un servicio de mensajería.
También hemos visto los conceptos de PubSub y rRPC y las diferencias entre un Message Service y un Message Queue. Finalmente, hemos repasado rápidamente algunos de los principales protocolos de IoT disponibles actualmente.
En la próxima entrada veremos el protocolo MQTT, que será el que emplearemos más habitualmente en nuestros proyectos, y en la siguiente veremos distintos Brokers para MQTT. Mientras tanto, si tenéis alguna duda o queréis añadir algo ¡Podéis dejar vuestro comentario!