- MQTT se ha expandido durante 25 años desde que se publicó su primera especificación en octubre de 1999, pasando de ser un protocolo ligero para dispositivos pequeños y redes inestables a usarse en la industria, el hogar y las aplicaciones en general
- La estructura simple de publicación/suscripción, pensada para energía limitada y conexiones intermitentes, sigue siendo una fortaleza incluso después de que cambiaran las redes y los entornos de dispositivos de borde
- MQTT, que se usaba alrededor de IBM, empezó a difundirse de verdad en la comunidad entre 2009 y 2011, y a través de Mosquitto y Eclipse Paho se amplió hacia un ecosistema de protocolo abierto fuera de IBM
- Hoy está presente incluso en lugares donde los usuarios no lo notan: procesamiento de mensajes en Raspberry Pi con Node-RED, purificadores de aire Dyson y sus apps, control de impresoras 3D, notificaciones del hogar y entornos de manufactura
- Con motivo de su 25.º aniversario, la comunidad dejó atrás la antigua cuenta del proyecto en X y se mudó a Mastodon con @mqtt@fosstodon.org, además de publicar su primer mensaje en el Fediverse basado en ActivityPub
Mensajería ligera nacida en entornos limitados
- Octubre de 2024 marca el 25.º aniversario de la publicación del documento que llevaría a la primera especificación de MQTT
- MQTT es un protocolo de red diseñado bajo la premisa de los dispositivos pequeños y limitados, y de las redes ligeras o inestables de finales de los años 90
- Se enfocó en enviar datos de sensores a sistemas más grandes en situaciones con conectividad intermitente y energía limitada, como dispositivos de monitoreo ambiental en ubicaciones remotas
- Estos dispositivos necesitaban ahorrar energía, ancho de banda y disponibilidad de red
- MQTT encajaba bien con una forma de publicar, recopilar y recibir datos en un formato pequeño pero útil
- Incluso después de que las redes se volvieran más rápidas y estables, y aumentaran los dispositivos de borde, la automatización del hogar y los dispositivos portátiles, la simplicidad del protocolo sigue siendo una fortaleza clave de MQTT
De los alrededores de IBM a un ecosistema abierto
- Tras unirse a IBM en 2001, el autor trabajó en proyectos de clientes relacionados con IBM MQ, integración de negocios, colas de mensajes, conexión de aplicaciones y middleware
- El laboratorio IBM Hursley era la base de MQ y también el centro de actividad de Andy Stanford-Clark, cocreador de MQTT, y fue en ese entorno donde comenzaron los experimentos con MQTT
- En ese entonces, MQTT ya se había publicado externamente como protocolo, pero fuera de IBM no era muy conocido ni estaba ampliamente implementado
- Alrededor de 2009 a 2011 avanzaron los esfuerzos para dar a conocer MQTT más allá del pequeño alcance de implementación dentro de IBM
- En ese momento, las opciones de broker eran IBM WebSphere Message Broker, orientado a empresas y costoso; microbroker, de código cerrado; y Really Small Message Broker, también cerrado pero distribuido gratuitamente
- Mosquitto, el proyecto de código abierto creado por Roger Light, sigue siendo hoy una de las implementaciones gratuitas más utilizadas
- Roger Light creó Mosquitto después de escuchar en el primer OggCamp de 2009 una charla de Andy Stanford-Clark sobre hogar inteligente conectado; eso ocurrió 10 años después de la fecha de creación de la especificación
Eclipse Paho y la estandarización oficial
- En 2011, la implementación de MQTT de IBM fue donada a la comunidad Eclipse y así comenzó el proyecto Eclipse Paho
- Incluso después de dejar IBM en 2012, continuó la relación con el proyecto Paho, y el autor también tuvo un rol durante su etapa en Cloud Foundry
- Tras unirse a Twitter en 2014, se apartó de la participación formal
- Durante ese periodo, MQTT pasó por procesos de estandarización oficial en OASIS e ISO/IEC
El MQTT invisible de hoy
- MQTT se convirtió en un caso de éxito de protocolo abierto más allá de los límites de IBM, y 25 años después está integrado en muchos productos y lugares sin que los usuarios lo noten
- Algunos usos representativos son:
- proyectos de desarrolladores aficionados y makers
- purificadores de aire Dyson y sus apps relacionadas
- sistemas de control de impresoras 3D
- sistemas de notificaciones del hogar
- entornos industriales y de manufactura
- Incluso en el espacio de trabajo personal, MQTT se usa de varias maneras
- La impresora 3D Bambu Lab X1C usa MQTT para su comunicación interna
- Los dispositivos conectados en la pared reaccionan a notificaciones MQTT para mostrar datos o encender luces
- Node-RED, ejecutándose en una Raspberry Pi, procesa mensajes MQTT
- Es muy probable que al menos una de las apps de tu teléfono use MQTT en alguna parte de su stack
El aniversario número 25 y el movimiento de la comunidad
- La cuenta comunitaria de MQTT se trasladó a Mastodon en lugar de seguir usando la antigua cuenta del proyecto en X
- La nueva cuenta se puede seguir en @mqtt@fosstodon.org
- Para celebrar el 25.º aniversario, MQTT publicó su primer mensaje en el Fediverse mediante ActivityPub y se sumó a la open social web
- Andy Stanford-Clark participó en una fireside chat con HiveMQ, y también se menciona el pódcast de HiveMQ, The Unstructured Message, como otro lugar para ver más contenido relacionado con MQTT
1 comentarios
Opiniones de Hacker News
Mi primer proyecto que todavía está en operación y se usa todos los días fue convertir el mapa SVG del sistema de agua de tuberías/bombas/válvulas para fabricación de nieve y contra incendios de un gran resort de esquí en un sitio web de visualización de estado.
Creé topics de MQTT para cada bomba, válvula y tramo de tubería, y les asocié estados como dirección del flujo de agua, encendido/apagado de bombas/válvulas y presión; actualizaba los colores y rellenos del SVG con mqtt.js y jQuery.
Un broker MQTT levantado en un contenedor sobre hosting estático lleva casi 10 años funcionando sin tocarlo, y mqtt.js opera sobre WebSockets, así que cuando cambia un estado se refleja automáticamente para todos.
Probé MQTT en un proyecto reciente, pero no me convenció mucho.
El protocolo tiene muchas opciones, y no era fácil entender de inmediato qué hace cada una, por qué es importante y en qué combinación hay que usarlas para que se comporten como uno espera; la documentación tampoco lo explicaba bien.
En parte quizá fue culpa del cliente Python de Eclipse Mosquitto que usé, pero en un sistema lento aparecían condiciones de carrera que hacían que las suscripciones a topics se ignoraran silenciosamente y que los callbacks se rompieran; me tomó días descubrirlo.
Eso pasó aun siguiendo la documentación al 100%, y para un protocolo no tan viejo fue una de las experiencias más desordenadas que he tenido.
Mi experiencia con los clientes de Eclipse, por ejemplo Paho en Python y C++, fue similar: se sentían demasiado complejos, demasiado de bajo nivel, y por su estructura tenían algunos bugs.
Probablemente terminaron así con el tiempo porque los mantiene prácticamente una sola persona. El cliente de C++ también tuvo solo un colaborador en los últimos 6 meses y nadie contribuyó en los últimos 3 meses.
Un PR simple que arreglaba un bug evidente, casi del nivel de cambiar una sola palabra, tardó 2 años en revisarse y fusionarse. No lo digo como acusación, sino que parece una situación con muchas librerías, bugs y trabajo, atendida por un pequeño grupo de personas sobrecargadas.
Al pasar a otros clientes, la experiencia en Python, Rust, C# y C++ mejoró muchísimo; la mayoría tenía una buena combinación de APIs de alto y bajo nivel, así que si solo querías enviar mensajes a un topic no tenías que preocuparte por confirmaciones ni reintentos.
En cambio, si necesitabas control, también podías tenerlo. Me preocupa que mantener vivo Paho y similares en su estado actual quizá haga más daño que bien. Si estuviera oficialmente muerto, al menos el problema saldría a la luz por fuerza; ahora los usuarios tienen estas experiencias y abandonan MQTT o piensan que ellos están haciendo algo mal.
Me molestó todo: el diseño de la API, la documentación pobre y la forma en que parece no seguir las convenciones de Python.
Empezar parece fácil, pero la amplitud del protocolo y de la implementación te va trabando cada vez más. En un momento, la forma confiable de comprobar si te habías conectado correctamente al servidor era suscribirte dos veces al mismo topic y capturar un código de error específico en el mensaje
on_connect. En ese entonces, ese código figuraba en la documentación como código de éxito.Sé que suena absurdo, pero aunque hubiera una mejor manera, no era fácil encontrarla. Aun así, quejarse es fácil, y agradezco a las muchas personas que hicieron esta librería. Sin ellas no podría haber construido lo que construí, y respeto a quienes se hacen cargo de proyectos enormes como este.
Cuando puedo, prefiero manejar el protocolo con
mosquitto_subymosquitto_pub, y limitarme a leer y escribir por entrada/salida estándar.No fue solo por los bugs; también era más fácil dejar la gestión de la conexión con el broker en manos de programas ya escritos y probados.
Eso sí, con los mensajes de última voluntad este enfoque no me funcionó de manera efectiva, y tampoco sirve para microcontroladores que no corren algo como Linux.
En la práctica crea un sistema de pipes *nix en red y autenticado, con el objetivo de ser la forma más simple de enviar y recibir eventos.
En mi caso de uso era importante tener una cola infinita, y MQTT no la ofrecía; si de todos modos yo tenía que gestionar IDs de mensajes para que MQTT pudiera rastrear sus propios IDs y enviarlos al broker, no veía razón para usarlo.
Si no estás integrándote con un proyecto ya adaptado a MQTT, no tengo muy claro cuál es su caso de uso ideal.
En los últimos años, MQTT se está usando mucho más dentro de las fábricas para compartir datos entre máquinas
Históricamente se usaba en el sector de Oil & Gas para SCADA, trayendo datos de sitios remotos de pozos petroleros
Hace más de 10 años agregué MQTT a Kepware (servidor OPC) para hacer streaming de valores de tags a la “nube”; después de la presentación, Arlen Nipper, uno de los creadores de MQTT, se acercó y dijo que “habíamos hecho un buen trabajo”, lo que me dejó con humildad
Ahora, en una nueva empresa llamada HighByte, estamos modelando datos de planta en el edge y enviándolos por MQTT, SparkplugB (un protocolo sobre MQTT), S3, Azure Blob, etc.
En resumen, MQTT es un gran impulsor de Industry 4.0, y es genial que siga usándose tanto después de tanto tiempo
Es algo tosco y tiene más etapas de procesamiento de las que quisiéramos. Como Kepware cobra una licencia recurrente anual por el plugin IoT, ahora estamos saliendo de esa solución y migrando a que telegraf lea datos OPC-UA directamente desde Kepware
Me da curiosidad si trabajaste o trabajas en Kepware
Ojalá simplemente usaran Sparkplug B e implementaran encima una especificación para semántica
Además, el trabajo que están haciendo ahora sobre asincronía está demasiado sobrediseñado y es pésimo. Participé en reuniones durante un tiempo, y aunque la especificación de MQTT no llega a 50 páginas y es fácil de leer, no la habían leído y ni siquiera entendían para qué servían los headers. Por ejemplo, querían poner en el header cosas que en realidad deberían ir en el payload
A una persona de Microsoft incluso le molestó la sugerencia de ver primero qué estaban haciendo los competidores con MQTT. Porque quería crear algo nuevo en vez de copiar
Por recomendación mía, en nuestra empresa vamos a tratar OPC UA solo en el borde más extremo y a aislarlo lo más posible de nuestra tecnología
Aunque últimamente también veo que Kafka y RabbitMQ están entrando cada vez más en el territorio de mercado de MQTT
Hace unos 15 años, cuando los dispositivos IoT que tuiteaban no eran comunes, la casa de Andy Stanford Clark fue noticia
https://www.bbc.co.uk/blogs/technology/2009/06/things_that_t...
El protocolo central fue concebido en una época en la que enviar 1 byte por un enlace satelital costaba 1 dólar, por eso es increíblemente eficiente y también simple de implementar
Una vez, el único puerto que se podía usar en el firewall de un cliente era MQTT 1883
Era porque recibían datos de sensores de esa forma, y por más que lo pedíamos no abrían ningún otro puerto, así que lo esquivamos creando un wrapper TCP en tiempo real sobre MQTT
Un daemon TCP local multihilo escuchaba solicitudes salientes en un puerto específico, las envolvía en MQTT y las publicaba en un tópico único; el daemon del servidor detectaba ese tópico, lo desenvolvía y lo pasaba al proceso del servidor
Desde el punto de vista de la máquina cliente, parecía que establecía una conexión TCP en tiempo real con nuestro servidor, pero en el medio había un wrapper MQTT raro e invisible
Una vez que funcionó era elegante, pero depurarlo fue realmente doloroso, y nos llevó meses atravesar varios callejones sin salida hasta encajar todo correctamente
Ahora a la situación de no poder hacer nada y quedarse de brazos cruzados la llamamos “dejar que el proceso funcione”
Como dato curioso, Boost, la biblioteca de C++ más famosa, está revisando en este mismo momento si incluir la implementación
async-mqtt5(https://github.com/mireo/async-mqtt5) como Boost.MQTT: https://lists.boost.org/Archives/boost/2024/10/index.phpAnecdóticamente, la mayoría de las adopciones que vi fueron en los 2000 y a comienzos muy tempranos de los 2010, es decir, antes de que todos exigieran C++0x/C++11, y hoy lo veo solo rara vez
boost.org se siente como un viaje al pasado. Se ve exactamente como lo recuerdo alrededor de 2008, incluso con el “Get Boost” superpuesto sobre un botón de parada de emergencia
MQTT es un pequeño protocolo realmente bueno; no solo es “lo suficientemente pequeño” como para usarlo en proyectos hobby, sino que escala lo suficiente como para usarse en cosas como Facebook Messenger
[1]: https://engineering.fb.com/2011/08/12/android/building-faceb...
No me convence mucho la promoción de que MQTT sea ligero y eficiente
Al final no es más que usar TCP/IP y, aunque quizá en ese momento eso podía ser relativamente especial, no he visto evidencia real que respalde esa afirmación más allá de la fanfarronería constante
Está bien que, al ser un estándar, puedas conectarte a dispositivos comerciales que lo soportan. Aun así, creo que hay mejores opciones para publicación/suscripción o colas de mensajes, especialmente si necesitas conmutación por error del lado del consumidor
Lo bueno de MQTT, y lo que casi todas las demás implementaciones de publicación/suscripción que he visto hacen mal, es que la estructura de datos central de MQTT no son las colas ni los tópicos, sino el cliente suscrito
Por eso puedes mapear un espacio de direcciones tan grande como quieras al árbol de tópicos. El árbol de tópicos puede tener billones de endpoints y, si quieres, incluso en un servidor embebido puedes tener un endpoint por cada dirección IPv6
Como el árbol de tópicos es rico, puedes hacer las suscripciones tan selectivas como necesites, y el servidor puede funcionar rápido incluso usando pocos recursos
He usado MQTT durante años en clases de IoT y ha demostrado ser una herramienta muy versátil
También es práctico que esté soportado vía WebSockets
En un proyecto reciente de sistemas embebidos, usé MQTT como sistema de mensajería entre procesos y fue bastante divertido
El broker y los clientes corrían en la misma máquina
Si necesitaba esnifar algo o depurar, bastaba con conectar el dispositivo a la red y usar MQTT Explorer para registrar o inyectar mensajes, así que era fácil
También podía abrir un puerto hacia fuera de la LAN para que un compañero trabajando en remoto pudiera manipular el sistema
Lo que más me preocuparía al usarlo como componente del sistema son las garantías de durabilidad, y no tengo mucha confianza en que la implementación del broker no vaya a perder datos