- MQTT s’est diffusé, en 25 ans depuis la publication de sa première spécification en octobre 1999, depuis un protocole léger destiné aux petits appareils et aux réseaux instables vers l’ensemble de l’industrie, de la maison connectée et des applications
- Sa structure simple de publication/abonnement, pensée pour une alimentation limitée et des connexions intermittentes, est restée un atout même après l’évolution des réseaux et des environnements d’appareils edge
- MQTT, utilisé autour d’IBM, a commencé à se diffuser largement dans la communauté entre 2009 et 2011, puis s’est élargi via Mosquitto et Eclipse Paho pour devenir un écosystème de protocole ouvert au-delà d’IBM
- Aujourd’hui, on le retrouve aussi dans des endroits dont les utilisateurs n’ont pas conscience : traitement de messages sur Raspberry Pi avec Node-RED, purificateurs d’air Dyson et leurs apps, contrôle d’imprimantes 3D, notifications domestiques, sites de production, etc.
- Pour son 25e anniversaire, la communauté a quitté l’ancien compte projet sur X au profit de @mqtt@fosstodon.org sur Mastodon, et a publié son premier message dans le Fediverse basé sur ActivityPub
Une messagerie légère née dans des environnements contraints
- Octobre 2024 marque le 25e anniversaire de la publication du document qui allait devenir la première spécification de MQTT
- MQTT est un protocole réseau conçu à la fin des années 1990 pour de petits appareils aux ressources limitées, et pour des réseaux légers ou instables
- Il visait à envoyer des données de capteurs vers des systèmes plus importants dans des situations où la connexion est intermittente et l’alimentation limitée, comme avec des équipements de surveillance environnementale éloignés
- Ces appareils doivent économiser l’énergie, la bande passante et la disponibilité réseau
- MQTT se prête bien à la publication, à la collecte et à la réception de données dans un format réduit mais utile
- Même après que les réseaux sont devenus plus rapides et plus fiables, et avec la multiplication de l’edge, de la domotique et des appareils portables, la simplicité du protocole est restée l’un des principaux atouts de MQTT
D’IBM à un écosystème ouvert
- Après avoir rejoint IBM en 2001, des projets clients ont été menés autour d’IBM MQ, de l’intégration métier, des files de messages, de la connexion d’applications et du middleware
- IBM Hursley Lab était le berceau de MQ et le lieu d’activité d’Andy Stanford-Clark, co-créateur de MQTT ; c’est dans cet environnement que les expérimentations autour de MQTT ont commencé
- À l’époque, MQTT était publié comme protocole à l’extérieur, mais il était peu connu ou largement implémenté hors d’IBM
- Vers 2009-2011, les efforts pour faire connaître MQTT au-delà du petit périmètre des implémentations IBM ont progressé
- Les options de brokers disponibles alors étaient IBM WebSphere Message Broker, destiné aux entreprises et coûteux, microbroker, en source fermée, et Really Small Message Broker, également en source fermée mais fourni gratuitement
- Mosquitto, l’implémentation open source créée par Roger Light, reste aujourd’hui l’une des implémentations gratuites les plus utilisées
- Roger Light a créé Mosquitto après avoir assisté, lors du premier OggCamp en 2009, à une présentation d’Andy Stanford-Clark sur sa maison connectée ; c’était dix ans après la date de création de la spécification
Eclipse Paho et la normalisation officielle
- En 2011, l’implémentation MQTT d’IBM a été donnée à la communauté Eclipse, lançant le projet Eclipse Paho
- Même après son départ d’IBM en 2012, le lien avec le projet Paho s’est poursuivi, avec un rôle conservé également pendant la période chez Cloud Foundry
- Après son arrivée chez Twitter en 2014, l’implication officielle a pris fin
- À cette période, MQTT a suivi un processus de normalisation officiel auprès d’OASIS et de l’ISO/IEC
MQTT aujourd’hui, là où on ne le voit pas
- MQTT a dépassé les frontières d’IBM pour devenir un cas de réussite de protocole ouvert, et 25 ans plus tard, il est présent dans de nombreux produits et lieux sans que les utilisateurs s’en rendent compte
- Parmi ses usages représentatifs :
- Projets de développeurs amateurs et de makers
- Purificateurs d’air Dyson et applications associées
- Systèmes de contrôle d’imprimantes 3D
- Systèmes de notifications domestiques
- Sites industriels et de production
- Dans un espace de travail personnel aussi, MQTT est utilisé de plusieurs manières
- L’imprimante 3D Bambu Lab X1C utilise MQTT pour ses communications internes
- Des appareils connectés au mur réagissent aux notifications MQTT pour afficher des données ou allumer des lumières
- Node-RED exécuté sur un Raspberry Pi traite des messages MQTT
- Il est très probable qu’au moins une application présente sur un smartphone utilise elle aussi MQTT quelque part dans sa stack
25e anniversaire et migration de la communauté
- Le compte communautaire MQTT a migré vers Mastodon, à la place de l’ancien compte projet sur X
- Le nouveau compte peut être suivi à l’adresse @mqtt@fosstodon.org
- Pour célébrer son 25e anniversaire, MQTT a publié son premier message dans le Fediverse via ActivityPub et a rejoint l’open social web
- Andy Stanford-Clark a participé à un fireside chat avec HiveMQ, et le podcast de HiveMQ, The Unstructured Message, est également présenté comme une ressource pour en savoir plus sur MQTT
1 commentaires
Avis sur Hacker News
Le premier projet encore en production et utilisé chaque jour consistait à prendre une carte SVG du réseau de canalisations/pompes/vannes pour l’enneigement artificiel et la lutte contre l’incendie d’une grande station de ski, puis à en faire un site web d’affichage d’état
Un topic MQTT avait été créé pour chaque pompe, vanne et section de conduite, avec des états comme le sens d’écoulement de l’eau, l’activation/désactivation des pompes et vannes, ou la pression, et les couleurs et remplissages du SVG étaient mis à jour avec mqtt.js et jQuery
Un broker MQTT lancé en conteneur sur un hébergement statique tourne presque sans intervention depuis près de 10 ans, et mqtt.js fonctionne au-dessus de WebSocket, ce qui répercute automatiquement les changements d’état à tout le monde
J’ai essayé d’utiliser MQTT dans un projet récent, mais je n’ai pas été très convaincu
Le protocole a beaucoup d’options, et il n’était pas facile de comprendre immédiatement ce que chacune faisait, pourquoi elle était importante, ni quelle combinaison utiliser pour obtenir le comportement voulu, et la documentation n’aidait pas vraiment
Une partie du problème venait peut-être du client Python Eclipse Mosquitto utilisé, mais il a fallu plusieurs jours pour découvrir que, sur un système lent, des conditions de concurrence faisaient que l’abonnement à des topics était silencieusement ignoré et que les callbacks cassaient
C’était le cas alors même que j’avais suivi la documentation à 100 %, et pour un protocole pas si ancien, ça a été l’une des expériences les plus brouillonnes que j’aie eues
J’ai eu une expérience similaire avec les clients Eclipse, par exemple Paho, en Python et en C++ : c’était excessivement complexe, trop bas niveau dans sa conception, et il y avait aussi quelques bugs dus à la structure
On dirait que c’est plus ou moins maintenu par une seule personne, et que le temps a fini par produire cet état. Le client C++ n’a eu qu’un seul contributeur sur les 6 derniers mois, et aucun sur les 3 derniers mois
Même une PR simple corrigeant un bug évident, ou changeant un seul mot, a pris 2 ans avant d’être revue et fusionnée. Ce n’est pas une critique, mais plutôt le constat qu’il y a des bibliothèques, des bugs et du travail en quantité, gérés par un petit nombre de personnes surchargées
En passant à d’autres clients, l’expérience a été bien meilleure en Python, Rust, C#, et C++, la plupart offrant une bonne combinaison d’API haut niveau et bas niveau, de sorte que si l’on veut juste envoyer des messages sur des topics, on n’a pas à se soucier des accusés de réception ou des tentatives de réémission
Et à l’inverse, si l’on a besoin de contrôle, on peut en avoir. Je crains qu’à l’état actuel, garder paho et consorts en vie ne fasse plus de mal que de bien. Si c’était officiellement mort, au moins le problème apparaîtrait clairement, alors qu’aujourd’hui les utilisateurs vivent ce genre d’expérience et abandonnent MQTT, ou pensent qu’ils s’y prennent mal
Tout était irritant : la conception de l’API, la documentation pauvre, jusqu’à cette impression que la bibliothèque ne suivait pas vraiment les conventions Python
Au début, cela semble facile, mais l’ampleur du protocole et de l’implémentation finit par devenir un obstacle. À une époque, la seule méthode fiable pour vérifier qu’on s’était bien connecté au serveur consistait à s’abonner deux fois au même topic et à intercepter un code d’erreur spécifique dans le message
on_connect. À ce moment-là, ce code était documenté comme un code de succèsÇa paraît absurde, mais même s’il existait une meilleure méthode, elle n’était pas facile à trouver. Cela dit, il est facile de se plaindre, et je remercie les nombreuses personnes qui ont créé cette bibliothèque. Sans elles, je n’aurais pas pu construire ce que j’ai construit aujourd’hui, et j’ai du respect pour celles et ceux qui prennent en charge des projets aussi énormes
Quand c’est possible, je préfère laisser
mosquitto_subetmosquitto_pubgérer le protocole et me contenter de lire et écrire sur l’entrée/sortie standardCe n’est pas seulement à cause des bugs : il était plus simple de confier la gestion de la connexion au broker à un programme déjà écrit et testé
En revanche, cette approche ne fonctionnait pas efficacement pour les messages testamentaires, et elle ne convient pas non plus aux microcontrôleurs qui ne font pas tourner quelque chose comme Linux
Il construit en pratique un système de tubes *nix en réseau et authentifié, avec pour objectif d’être la manière la plus simple d’envoyer et de recevoir des événements
Dans mon cas d’usage, une file d’attente infinie était importante, et MQTT ne fournissait pas cela. Et si je devais de toute façon gérer moi-même des identifiants de message pour suivre ceux que MQTT surveille déjà de son côté avant de les envoyer au broker, je ne voyais pas l’intérêt de l’utiliser
À moins de devoir s’intégrer à un projet déjà construit autour de MQTT, je ne vois pas très bien quel est son meilleur cas d’usage
Ces dernières années, MQTT est bien davantage utilisé pour partager des données entre machines à l’intérieur des usines.
Historiquement, il servait pour le SCADA afin de remonter les données de sites de puits de pétrole distants dans le secteur Oil & Gas.
Il y a plus de 10 ans, j’ai ajouté MQTT à Kepware (serveur OPC) pour diffuser des valeurs de tags vers le « cloud », et après la présentation, Arlen Nipper, l’un des créateurs de MQTT, est venu me dire que c’était « pas mal », ce qui m’a rendu humble.
Aujourd’hui, je suis dans une nouvelle société appelée HighByte, où nous modélisons les données d’usine à l’edge et les envoyons via MQTT, SparkplugB (un protocole au-dessus de MQTT), S3, Azure Blob, etc.
En bref, MQTT est un grand moteur de l’Industry 4.0, et c’est génial de voir qu’il est encore autant utilisé après tout ce temps.
C’est un peu rustique et il y a plus d’étapes de traitement que je ne le souhaiterais. Comme Kepware facture des frais de licence annuels récurrents pour le plugin IoT, nous sommes en train d’abandonner cette solution pour passer à telegraf, qui lira directement les données OPC-UA depuis Kepware.
Je me demande si vous avez travaillé ou travaillez chez Kepware.
J’aimerais qu’on utilise simplement Sparkplug B et qu’on implémente au-dessus une spécification pour la sémantique.
En plus, le travail asynchrone en cours est beaucoup trop surconçu et médiocre. J’ai participé aux réunions pendant un temps, et alors même que la spécification MQTT fait moins de 50 pages et se lit facilement, ils ne l’avaient jamais lue et ne comprenaient même pas à quoi servent les headers. Par exemple, ils essayaient de mettre dans les headers ce qui devrait en réalité aller dans le payload.
Côté Microsoft, une personne s’est même vexée quand j’ai proposé de regarder d’abord ce que faisaient les concurrents avec MQTT. Elle préférait recréer quelque chose plutôt que copier.
Sur ma recommandation, notre entreprise ne gérera OPC UA qu’au tout dernier niveau de l’edge, en l’isolant autant que possible du reste de notre technologie.
Cela dit, on voit aujourd’hui Kafka et RabbitMQ empiéter davantage sur le terrain de MQTT.
Il y a environ 15 ans, à une époque où les appareils IoT qui tweetaient n’étaient pas encore monnaie courante, la maison d’Andy Stanford Clark avait fait parler d’elle.
https://www.bbc.co.uk/blogs/technology/2009/06/things_that_t...
Le protocole de base a été conçu à une époque où l’envoi d’un octet sur une liaison satellite coûtait 1 dollar, donc il est incroyablement efficace et simple à implémenter.
Une fois, chez un client, le seul port utilisable à travers le pare-feu était MQTT 1883.
C’est parce qu’ils recevaient ainsi les données des capteurs, et malgré toutes nos demandes ils n’ouvraient aucun autre port, donc nous avons contourné cela en construisant un wrapper TCP temps réel sur MQTT.
Un démon TCP local multithread écoutait les requêtes sortantes sur un port donné, les encapsulait dans MQTT puis les publiait sur un topic unique, et un démon serveur détectait ce topic, les décapsulait puis les transmettait au processus serveur.
Du point de vue de la machine cliente, cela ressemblait à une connexion TCP temps réel vers notre serveur, mais au milieu il y avait un étrange wrapper MQTT invisible.
Une fois que cela a fonctionné, c’était élégant, mais le débogage a été un vrai cauchemar, et il a fallu des mois, avec beaucoup d’impasses, pour que l’ensemble s’emboîte correctement.
Maintenant, j’appelle le fait de ne rien pouvoir faire et de devoir se tourner les pouces « laisser le processus suivre son cours ».
Fait amusant, Boost, la bibliothèque C++ la plus connue, examine en ce moment même l’intégration de l’implémentation
async-mqtt5(https://github.com/mireo/async-mqtt5) dans Boost.MQTT : https://lists.boost.org/Archives/boost/2024/10/index.phpAnecdotiquement, l’adoption remonte surtout aux années 2000 et au tout début des années 2010, avant que tout le monde n’impose C++0x/C++11, et je le vois rarement de nos jours.
boost.org ressemble à un voyage dans le passé. Il a exactement l’apparence dont je me souviens vers 2008, y compris le « Get Boost » incrusté sur le bouton d’arrêt d’urgence.
MQTT est vraiment un bon petit protocole, assez « petit » pour être utilisé dans des projets hobby, mais aussi capable de monter en charge au point d’être utilisé dans quelque chose comme Facebook Messenger.
[1]: https://engineering.fb.com/2011/08/12/android/building-faceb...
J’ai du mal à adhérer à la promotion de MQTT comme quelque chose de léger et d’efficace.
Au final, ça n’utilise que TCP/IP ; à l’époque, c’était peut-être relativement particulier, mais je n’ai jamais vu de preuves concrètes pour étayer ce genre d’affirmation, à part une autosatisfaction répétée.
Le fait que ce soit un standard et qu’on puisse le connecter à des appareils existants pris en charge est un bon point. Cela dit, je pense qu’il existe de meilleurs choix pour le publication/abonnement ou les files de messages, surtout si on a besoin de tolérance aux pannes côté consommateurs.
Ce qui est bien avec MQTT — et ce que presque toutes les autres implémentations de publication/abonnement que j’ai vues font mal —, c’est que sa structure de données centrale n’est ni la file ni le topic, mais le client abonné.
On peut donc mapper un espace d’adressage aussi grand qu’on le souhaite sur un arbre de topics. Cet arbre peut avoir des billions de points de terminaison et, si on le veut, même sur un serveur embarqué, on peut avoir un point de terminaison pour chaque adresse IPv6.
Comme l’arbre de topics est riche, on peut rendre les abonnements aussi sélectifs que nécessaire, et le serveur peut fonctionner rapidement avec une faible consommation de ressources.
J’utilise MQTT depuis plusieurs années dans des cours sur l’IoT, et il a prouvé que c’était un outil très polyvalent.
Le fait qu’il soit aussi pris en charge via WebSocket est pratique.
J’ai récemment trouvé assez amusant d’utiliser MQTT comme système de messagerie inter-processus dans un projet de systèmes embarqués.
Le broker et les clients tournaient sur la même machine.
Quand il fallait sniffer quelque chose ou déboguer, il suffisait de connecter l’appareil au réseau et d’utiliser MQTT Explorer pour enregistrer ou injecter des messages, ce qui était pratique.
On pouvait aussi ouvrir un port vers l’extérieur du LAN pour qu’un collègue en télétravail puisse manipuler le système.
Ce qui m’inquiéterait le plus si on l’utilisait comme composant système, ce sont les garanties de durabilité ; je n’ai pas une grande confiance dans le fait qu’une implémentation de broker ne perdra pas de données.