Protocole MQTT
- 1. Introduction à MQTT
- 2. Modèle publish/subscribe (pub/sub)
- 3. Etablissement de connexion MQTT Client/Broker
- 4. Messages Publish, Subscribe et Unsubscribe
- 5. Topics MQTT
- 6. Qualité de Service
- 7. Persistence des messages et gestion des files d'attente
- 8. Messages "retained" de garde
- 9. Fonctionnalités dernière volonté et testatment
- 10. MQTT Keep Alive et Client Take-Over
- 11. MQTT sur WebSockets
- Sources
MQTT est un protocole de messagerie ISO-ISO (IEC/PRF 20922) basé sur un modèle publish/subscribe. I fonctionne au-dessus du protocole TCP/IP comme protocole de couche Application. Il est conçu pour les connexions avec des emplacements distants où une "empreinte réduite de code" est requise ou si la bande passante du réseau est limitée. Le modèle de messagerie de publish/subscribe requiert un broker de messages.
La spécification ne précise pas la signification de "empreinte réduite de code" ou la signification de "bande passante réseau limitée". Ainsi, la disponibilité du protocole dépend du contexte. En 2013, IBM a soumis MQTT v3.1 à l'organisme de spécification OASIS avec une charte garantissant que seules des modifications mineures de la spécification pourraient être acceptées. MQTT For Sensor Networks (MQTT-SN) est une variante du protocole principal destiné aux périphériques embarqués sur des réseaux non-TCP/IP, tels que ZigBee.
Andy Stanford-Clark d'IBM et Arlen Nipper de Cirrus Link ont rédigé la première version du protocole en 1999. Historiquement, le "MQ" dans "MQTT" provenait de la gamme de produits de mise en file d'attente des messages MQ Series d'IBM. Toutefois, la mise en file d'attente elle-même n'est pas nécessaire pour être prise en charge en tant que fonctionnalité standard dans toutes les situations.
Des protocoles alternatifs sont par exemple :
- le protocole AMQP (Advanced Message Queuing Protocol),
- le protocole STOMP (Streamed Text Oriented Messaging Protocol),
- les protocoles d'application contrainte IETF comme :
- XMPP,
- DDS,
- OPC UA
- et Web Application Messaging Protocol (WAMP).
1. Introduction à MQTT
MQTT is a Client Server publish/subscribe messaging transport protocol. It is light weight, open, simple, and designed so as to be easy to implement. These characteristics make it ideal for use in many situations, including constrained environments such as for communication in Machine to Machine (M2M) and Internet of Things (IoT) contexts where a small code footprint is required and/or network bandwidth is at a premium.
Citation de la Spécification officielle MQTT 3.1.1 que l'on pourrait traduire par :
MQTT est un protocole de transport de messages en modèle Client/Server publish/subscribe. Il est léger, ouvert, simple et conçu pour être facile à mettre en oeuvre. Ces caractéristiques le rendent idéal dans de nombreuses situations, notamment dans des environnements contraints tels que la communication machine à machine (M2M) et l'Internet des objets (IoT) où une empreinte de code réduite est requise et/ou la bande passante réseau est cruciale.
Il s'agit d'un protocole très léger et binaire qui excelle lors du transfert de données sur le réseau par rapport à des protocoles comme HTTP par ce que la surchage en en-têtes est moins importante. Un autre aspect important à relever la facilité de mise en oeuvre du protocole MQTT du côté client. Cette facilité convient parfaitement aux dispositifs contraints avec des ressources limitées. En fait, il s'agit là d'un des objectifs de départ de MQTT.
1. Historique
MQTT a été inventé par Andy Stanford-Clark (IBM) et Arlen Nipper (Arcom, maintenant Cirrus Link) en 1999. Leur cas d'usage était de créer un protocole avec une perte de charge électrique et une bande passante minimales. Ils ont spécifié les objectifs du futur protocole :
- Simple à mettre en oeuvre
- Livraison de données avec qualité de service
- Léger et efficient avec la bande passante
- Agnostique quant aux données
- Maintenance des sessions
Ces objectifs sont toujours au coeur de MQTT tandis que l'attention s'est déplacée des systèmes intégrés propriétaires aux cas d'usage de l'Internet des objets. Il y a souvent une confusion quant à la signification appropriée de l'abréviation MQTT. La réponse courte est que MQTT n'a officiellement plus d'acronyme, c'est juste MQTT. La réponse longue histoire raconte que l'ancien acronyme signifiait "Transport de télémétrie MQ" (Message Queuing Telemetry Transport), alors que MQ fait référence à "MQ Series", un produit développé par IBM qui prend notamment en charge MQTT. Le protocole a été nommé après quand il a été inventé 1999.
Souvent MQTT est incorrectement nommé comme protocole de file d'attente. Il n'y a pas de files d'attente comme dans les solutions traditionnelles de mise en file d'attente des messages. Cependant, il est possible de mettre en file d'attente des messages dans certains cas. Donc, après que MQTT ait été utilisé par IBM en interne pendant un certain temps, la version 3.1 est sortie libre de droits en 2010. À partir de là, tout le monde a pu l'implémenter et l'utiliser.
Environ trois ans après la publication initiale, le 29 octobre 2014, MQTT devait être normalisé sous comme standard OASIS, une organisation ouverte ayant pour but de faire progresser les normes. MQTT 3.1.1 est la dernière version du protocole.
2. Modèle publish/subscribe (pub/sub)
Le modèle publish/subscribe (pub/sub) est une alternative au modèle "client/serveur" traditionnel dans lequel un client communique directement avec un point de terminaison. Le modèle "Pub/Sub" dissocie le client qui envoie un message particulier (appelé publisher) d'un autre client (ou plusieurs clients) qui reçoit le message (appelé subscriber). En conséquence, le publisher et le subscriber ne se connaissent pas l'un l'autre. Il existe un troisième composant, appelé le broker, qui est connu à la fois par le publisher et le subscriber qui filtre tous les messages entrants et les distribue en conséquence.
[Diagramme]
L'élément fondamental dans le modèle "pub/sub" est la dissociation des clients publisher et subscriber.
Ceux-ci peuvent être différenciés sous plusieurs dimensions:
- Dissociation spatiale : le publisher et le subscriber n'ont pas besoin de se connaître (adresse IP et port par exemple) :
- Dissociation temporelle : le publisher et le subscriber n'ont pas besoin de s'exécuter en même temps.
- Dissociation de synchronisation : les opérations sur les deux éléments ne sont pas interrompues lors de la publication ou de la réception.
En résumé, le modèle publish/subscribe dissocie l'éditeur (publisher) et le destinataire (subscriber) d'un message. Grâce à un filtrage des messages il est possible que seulement certains clients reçoivent certains messages. Le découplage a donc trois dimensions: espace, temps et synchronisation.
Evolutivité
L'évolutivité est aussi une des caractéristiques du modèle "pub/sub" par rapport à l'approche traditionnelle "client/serveur". En effet, les opérations sur le broker peuvent être fortement parallélisées et traitées par événements. De même, la mise en cache des messages et leur routage intelligent sont souvent déterminants pour améliorer l'évolutivité. Pour supporter des millions de connexions, il peut être nécessaire de répartir les charges sur des cluster de brokers.
Filtrage
Le filtrage des messages est aussi une autre caractéristique du modèle "pub/sub".
- Option 1: Filtrage par sujet (topic). Le filtrage est basé sur un sujet (topic) qui fait partie de chaque message. Le client destinataire s'abonne sur les sujets qui l'intéressent sur le broker. Il reçoit alors tous les messages en fonction des sujets dans lesquels il s'est inscrit. Les sujets sont en général des chaînes avec une structure hiérarchique qui permettent le filtrage basé sur un nombre limité d'expressions.
- Option 2: Filtrage basé sur le contenu. Le filtrage basé sur le contenu filtre le message en fonction de règles de filtrage de contenu spécifiques. Un gros inconvénient est que le contenu du message doit être connu au préalable et ne peut être chiffré ou modifié facilement.
- Option 3: Filtrage par type. Dans les langages orientés objet, il est d'usage de filtrer en fonction du type ou de classe du message (événement). Dans ce cas, un abonné peut écouter tous les messages.
Difficultés
Quels sont les éléments qui posent des difficultés dans le modèle pub/sub ?
- D'abord, il faut connaître la structuration des données au préalable. Dans le cas d'un filtrage par sujet, l'éditeur et l'abonné doivent connaître les sujets appropriés à utiliser.
- Ensuite, quant à la livraison des messages, un publisher ne peut pas présumer que quelqu'un écoute ses messages. Par conséquent, il se peut qu'un message ne soit lu par aucun subscriber.
MQTT en modèle pub/sub
MQTT incarne tous les aspects mentionnés en fonction de ce que vous voulez réaliser avec.
MQTT découpe l'espace du publisher et du subscriber. Il leur suffit donc de connaître le nom d'hôte ou adresse ip et le port du broker pour publier ou s'abonner aux messages.
MOQTT se dissocie également avec le temps, mais souvent il s'agit simplement d'un comportement de repli, car le cas d'utilisation concernent principalement de la livraison de messages en temps quasi réel. Bien sûr, le broker est capable de stocker des messages pour les clients qui ne sont pas en ligne. (Cela nécessite deux conditions : le client s'est connecté une fois et sa session est persistante et il s'est abonné à un sujet avec une valeur QoS supérieure à 0).
MQTT est également capable de dissocier la synchronisation, car la plupart des bibliothèques clientes fonctionnent de manière asynchrone et sont basées sur des rappels (callbacks) ou modèle similaire. Ainsi, il ne bloquera pas d'autres tâches en attendant un message ou en publiant un message. Mais il existe certains cas d'utilisation où la synchronisation est souhaitable et également possible. Certaines bibliothèques ont donc des API synchrones pour attendre un certain message. Mais généralement, le flux est asynchrone.
Un autre élément qui devrait être mentionné est que MQTT est particulièrement facile à utiliser du côté client. La plupart des systèmes pub/sub dispose de la logique du côté broker, mais MQTT représente l'essence même du modèle "pub/sub" en utilisant une bibliothèque cliente qui en fait un protocole léger pour les périphériques petits et contraints.
MQTT utilise un filtrage par sujet des messages. Ainsi, chaque message contient un sujet (topic) que le broker utilise pour savoir si un client subscriber recevra le message ou non.
MQTT n'est une solution MQ (Message Queuing)
Quelles sont les différences entre MQTT et une file d'attente de messages traditionnelle ?
- Une file d'attente de messages stocke le message jusqu'à ce qu'ils soient consommés. Lors de l'utilisation des files d'attente de messages, chaque message entrant sera stocké dans cette file d'attente jusqu'à ce qu'il soit détecté par un client (souvent appelé consumer). Autrement, le message sera simplement bloqué dans la file d'attente et attendra d'être consommé. Il est impossible que les messages ne soient traités par aucun client comme c'est le cas dans MQTT si personne ne s'abonne à un sujet.
- Un message ne sera consommé que par un client. Une autre grande différence est le fait que dans une file d'attente traditionnelle, un message est traité par un seul consommateur. Alors que la charge peut être répartie entre tous les consommateurs pour une file d'attente particulière. Dans MQTT c'est tout à fait le contraire, chaque abonné reçoit le message s'il s'est abonné au sujet.
- Les files d'attente sont nommées et doivent être créées explicitement. Une file d'attente est beaucoup plus rigide qu'un sujet. Avant d'utiliser une file d'attente, elle doit être créée explicitement avec une commande séparée. Seulement après cette opération, il est possible de publier ou de consommer des messages. Les sujets MQTT sont extrêmement flexibles et peuvent être créés à la volée.