Message Queuing Telemetry Transport (MQTT) est un protocole de messagerie de publication/abonnement qui permet à deux appareils distants de communiquer par message de manière asynchrone avec une faible bande passante. Ce protocole, spécifiquement dédié au monde du M2M (machine to machine) et de l’IoT (Internet des Objets), est désormais considéré comme une standard du secteur.
Scaleway Elements IoT Hub implémente le protocole le plus utilisé dans le monde de l’IoT : MQTT 3.1.1.
Message Queuing Telemetry Transport (MQTT) est un protocole de messagerie de publication/abonnement basé sur TCP/IP et développé en 1999 par Andy Stanford-Clark de chez IBM et Arlen Nipper de chez EuroTech.
Ce protocole, spécifiquement dédié au monde du M2M (machine to machine) et de l’IoT (Internet des Objets), est désormais considéré comme une norme du secteur.
Le protocole MQTT permet à deux appareils distants de communiquer par message de manière asynchrone avec une faible bande passante. Ce type de protocole est de plus en plus utilisé pour la communication entre les objets connectés. Ces objets connectés collectent différentes informations provenant des capteurs intégrés, qui sont ensuite envoyées via MQTT.
Au cœur de tout protocole MQTT standard basé sur une structure IoT se trouve un serveur distant, appelé Broker. Tous les objets et services s'y connectent en tant que clients. Le Broker transmet les messages entre les clients. Les clients peuvent envoyer des messages en tant que publicateurs et recevoir des messages en tant que souscripteur. Les messages publiés contiennent un topic qui décrit le contenu du message (par exemple : la météo à Paris, France). Les souscripteurs reçoivent chacun une copie du message s'ils ont souscrit au sujet du message publié.
Fig 1 : Les souscripteurs s'abonnent à un topic auprès du Broker (Scaleway IoT Hub) (1), le publicateur publie des informations dans le topic auprès du Broker (2) et le Broker publie le sujet auprès des abonnés (3)
Dans le MQTT, les clients s'identifient à l'aide d'un ClientID unique. S'il est laissé vide, le Broker en génère un au hasard.
Lorsqu'un client MQTT se connecte au Broker, il peut choisir de démarrer une nouvelle session ou de reprendre la session existante. Une session contient les abonnements du Client et les messages en attente.
Les topics sont utilisés pour transmettre les messages publiés aux souscripteurs. Un sujet est une chaîne de caractères indiquant le contenu du message (exemple : maison/2eme etage/cuisine/temperature). Avec MQTT, par défaut, tous les souscripteurs reçoivent une copie des messages publiés avec les sujets correspondants.
N'hésitez pas à jeter un coup d'oeil à notre article sur les topics pour en savoir.
Lors de la publication d'un message, un client peut demander au Broker de garder en mémoire ce message. C'est ce qu'on appelle un retained message (message conservé). Tout abonnement futur correspondant au sujet du message conservé en recevra immédiatement une copie. Un nouveau message conservé pour le même sujet élimine le précédent.
Les niveaux de qualité de service de MQTT déterminent comment la relation entre le client et le Broker doit se dérouler lorsqu’ils communiquent. Ils indiquent le niveau de disponibilité relatif à la distribution d’un message entre les parties communicantes.
Veuillez noter que les Niveaux de Qualité de Service s'appliquent entre un client et le Broker, et non entre un publicateur et un souscripteur.
PUBLISH) ne peut être reçu qu’une seule fois. L’expéditeur ne stocke pas le message pour les futures transmissions. Par conséquent, si un message est envoyé et que le destinataire n’est pas disponible au moment de l’envoi, la charge utile ne lui parviendra pas. De plus, aucune confirmation de réception ne sera fournie.
PUBLISH) sera reçu au moins une fois. Dans ce cas, si l’expéditeur ne reçoit pas d’accusé de réception (PUBACK) dans le délai prévu, le message peut être envoyé plusieurs fois jusqu’à recevoir une confirmation. La confirmation est envoyée une seule fois par le destinataire en tant que réponse au message d’origine. Par conséquent, si l’expéditeur d’origine d’un message est indisponible au moment de l’acheminement de la réponse, il ne recevra pas de confirmation de réception et continuera à envoyer le même message jusqu’à en recevoir une. Cependant, le destinataire ne comprendra pas qu’il s’agit d’un message dupliqué et l’interprétera comme une nouvelle information.
PUBLISH).PUBACK).PUBREL).PUBCOMP).Ce niveau de qualité est le plus sécurisé, car il garantit que le message n’est pas interprété comme deux informations distinctes. Cependant, le flux QoS 2 requiert qu’une quantité plus importante de données soit véhiculée entre l’expéditeur et le destinataire, ce qui n’est pas vraiment approprié lorsqu’il s’agit de clients dont la capacité de mémoire est faible.
Lors de la connexion, le client peut fournir un message de Last Will (dernière volonté) au Broker. Il s'agit d'un message régulier qui sera publié par le courtier si le client se déconnecte inopinément. Ce mécanisme permet aux clients de s'assurer que les autres clients seront avertis lorsqu'ils se déconnectent, que ce soit correctement ou inopinément.
Le protocole MQTT dispose de plusieurs implémentations qui fonctionnent avec différents langages de programmation et environnements. Votre choix dépendra des types d’appareils avec lesquels vous travaillez et des outils MQTT dont vous disposez peut-être déjà.
Des logiciels appelés clients MQTT sont utilisés pour collecter ou traiter les données générées par les objets connectés. Ils peuvent être utilisés pour configurer un appareil en tant que client hub et pour configurer les actions à exécuter en fonction des messages reçus dans les topics auxquels les clients sont abonnés.
Certains appareils comme Arduino, Rapsberry Pi et quelques contrôleurs industriels disposent de plateformes de micro-calcul intégrées qui permettent la configuration via les clients MQTT intégrés. D’autres appareils peuvent nécessiter l’utilisation d’un logiciel tiers. Eclipse Paho est une alternative open source populaire.
Vous pouvez également trouver des clients basés sur le Web qui se connectent au hub via des sockets Web, tels que le client HiveMQ. Si vous avez besoin d’effectuer des tests sans utiliser de hardware, des outils tels que MQTT Lens et MQTT-Spy vous seront d’une aide précieuse, car ils simulent les clients MQTT.
Pour l’implémentation du broker, il existe plusieurs projets open source disponibles. Le plus utilisé est Mosquitto, qui fournit les versions 5.0, 3.1.1 et 3.1 du protocole MQTT. Le projet fournit une bibliothèque C (langage de programmation) pour l’implémentation des clients MQTT. Il prend également en charge les lignes de commande mosquitto_pub et mosquitto_sub des clients MQTT.
Chez Scaleway, nous allons plus loin avec IoT Hub, une plateforme qui autorise les appareils connectés à interagir avec les services cloud.
Scaleway IoT Hub fonctionne comme un broker MQTT. De plus, les Hub Routes permettent aux appareils de bénéficier de l’écosystème Scaleway. Par exemple, les Object Storage Routes vous permettent de stocker vos métriques dans un bucket Object Storage compatible S3. Les Database Routes servent à stocker des messages spécifiques dans une base de données et à déclencher l'exécution de toute requête SQL sur cette même base de données. Enfin, les REST Routes vous permettent de transmettre n’importe quel message publié sur un topic sélectionné vers un service REST.
Dans cet article, nous allons distinguer les différentes méthodes d'autoscaling fournies par Kubernetes et comprendre les différences entre l'horizontal pod autoscaler et le vertical pod autoscaler.
Suite aux événements récents, vous êtes très nombreux à nous interroger sur nos pratiques et nos moyens de protection dans nos datacenters. Nous allons vous répondre avec un maximum de transparence.
Familink a récemment migré l’intégralité de son infrastructure d’AWS à Scaleway. Apprenez de leur retour d'expérience comment stocker vos données en Europe.