Université Constantine 2 –Abdelhamid mehri

Faculté des nouvelles technologies

Département du IFA / Master 1 Matière DARE

TD N°2 : Rappel de la Modélisation UML (Diagramme de classe, de séquence)

Exercice 1 : Modélisation du protocole de communication MQTT
L’objectif d’étudier le protocole MQTT est double : d’un côté avoir une idée sur la communication dans les systèmes distribués
(Exemple un protocole de type publish/subscribe dans les systèmes Peer to Peer). De l’autre côté, rappeler la modélisation
d’un système par UML. Ainsi, ce protocole fera l’objet de plusieurs exercices tout au long de l’enseignement de la matière
DARE.
1. Description générale du MQTT :
Message Queue Telemetry Transport (MQTT) est un protocole de messagerie basé sur l’architecture publish/subscribe
(publication / abonnement), à la fois simple et extrêmement léger, il est conçu spécifiquement pour des applications de type
M2M (Machine to Machine).
MQTT est initialement créé en 1999 par Andy Stanford-Clark (IBM) et Arlen Nipper (Eurotech), pour le contrôle d’un pipeline
dans le désert. L’objectif était d’avoir un protocole de bande passante efficace utilisant peu d’énergie à un moment où les
périphériques ne pouvaient être connectés qu’au travers des satellites. Le protocole est standardisé par l’OASIS en 2014 dans
sa version 3.1.1. Il devient un standard ISO (ISO/IEC 20922) en 2016. Aujourd’hui, avec l’essor de l’Internet of Things
(Internet des objets connectés), MQTT suscite un intérêt grandissant (voir Google recherches).
L’intérêt majeur d’utiliser ce protocole est la notification en temps réel de la publication des nouvelles données sans
devoir constamment interroger un serveur ; cela apporte de la réactivité à nos applications sans surcharger le serveur de
requêtes inutiles
2. Les principales caractéristiques de MQTT sont les suivantes :
 Emploie le pattern publish/subscribe TCP/IP, permettant une distribution des messages un-à-plusieurs, ainsi que le
découplage des applications (i.e. indépendance des comportements internes).
 Particulièrement adapté pour utiliser une très faible bande passante,
 Idéal pour l’utilisation sur les réseaux sans fils,
 Faible consommateur en énergie,
 Très rapide, il permet un temps de réponse supérieur aux autres standards du web actuel,
 Nécessite peu de ressources processeurs et de mémoires.
 Le protocole de transport de messages est totalement indépendant de leur contenu (content agnostic).
 Trois niveaux de qualité de service pour la distribution des messages :Atmost once, At least once et Exactly once.
 Volume de données échangées extrêmement réduit, limitant ainsi le trafic réseau généré.
 Un mécanisme de notification en cas de déconnexion de façon anormale d’un client.
3. Principe de Fonctionnement du Protocole MQTT
MQTT est un service de publication/abonnement TCP/IP, il fonctionne sur le principe client/serveur.

Fig.1 Architecture du protocole MQTT.

Le serveur, nommé Broker, va collecter des informations que les Publishers vont lui transmettre. Les messages ne sont pas
envoyés d’un émetteur à un récepteur, mais sont échangés sur des files d’attente (les topics).
Un Subscriber peut s’abonner (message subscribe) à un topic pour recevoir les messages associés, sans forcément connaître
les Publishers qui vont émettre dessus. De la même manière, un Publisher va envoyer un message (publish) dans un topic
sans connaître les Subscribers qui se sont abonnées. Les abonnés (Subscribers), s’il y en a, sont alors notifiés et reçoivent le
message. Les clients sont donc de deux types : Publisher et Subscriber.

1
Université Constantine 2 –Abdelhamid mehri
Faculté des nouvelles technologies
Département du IFA / Master 1 Matière DARE

Un « topic MQTT » ou canal d’informations, c’est une chaîne de caractères permettant de sélectionner finement les
informations qu’on désire, elle peut avoir une hiérarchie de niveaux utilisant les caractèresspéciaux suivants : « / » « + » « # »
(voir l’exemple ci-après).
Les messages envoyés par les clients peuvent être de toutes sortes mais ne peuvent excéder une taille de 256 Mo.

Fig.2 Principe de fonctionnement du protocole MQTT.

Exemple : Le topic ‘/home/salon/temperature’ communiquera les températures du salon si un client s’y abonne (la sonde de
température (Object connecté) présente dans le salon publiera régulièrement la température relevée sur ce topic). Si
un publisher s’abonne au topic ‘/home/salon/#’ il recevra toutes les données du salon (on peut imaginer : luminosité, humidité,
température…). S’il s’abonne au topic ‘/home/#’, il collectera toutes les données des sondes de la maison.

Fig.3 Exemple de PUBLISH and SUBSCRIBE dans un système d’Internet of Things.

Les trois clients établissent une connexion TCP avec le broker. Les clients B et C souscrivent au topic « temperature ». Le Client
A publie sur le topic « temperature » une valeur de 22,5°. Le broker propage le message à tous les clients ayant préalablement
souscrit au topic « temperature ».
4. Les Eléments de Bases du Protocole MQTT
 Client-MQTT (= publisher, subscriber): Les clients s'abonnent à des topics pour publier et recevoir des messages.
Ainsi, les publishers et les subscribers sont des rôles spéciaux d'un client.
 Server-MQTT (= broker): les serveurs exécutent des topics, c'est-à-dire reçoivent des abonnements de clients sur
des topics, reçoivent des messages de clients et les transmettent, en fonction des abonnements du client, aux clients
intéressés.
 Topics : les topicssupportent le pattern de publication / abonnement pour les clients. Logiquement, les topics
permettent aux clients d'échanger des informations avec une sémantique définie.
 Session: matérialise la possibilité d’attachement du client au serveur, toute communication entre les deux passes par
une session.
 Subscription: attache un client à un topics de façons logique. Après une subscription à un ou plusieurs topics, le
client échange les messages avec le topic. Une subscription peut être temporaire ou durable (transient or durable),
cela dépend de l’information véhiculée dans le message de connexion, correspond à la valeur d’un Flag nommé clean
session (0-1) dans le message de connexion (CONNECT).
 Message: c’est l’unité d’information échangée entre les clients. Les messages sont typés comme suit : CONNECT,
CONNACK, PUBLISH, PUBACK, PUBREC, PUBCOMP, SUBSCRIBE, SUBACK, UNSUBSCRIBE,
UNSUBACK, PINGREQ, PINGRESP et DISCONNECT.
Université Constantine 2 –Abdelhamid mehri
Faculté des nouvelles technologies
Département du IFA / Master 1 Matière DARE

MQTT considère à la fois le serveur et le client comme des émetteurs et récepteur. La livraison d'un message peut
être soit d'un émetteur à un seul destinataire, soit d'un serveur à plus d'un destinataire (client).

5. Descriptions des différents scénarios du protocole MQTT :

a) Connexion et Déconnexion : Avant de pouvoir envoyer des commandes de contrôle, un client doit au préalable se
connecter (c’est enregistrement pas une connexion TCP) auprès du serveur, ce qui se fait avec la commande
CONNECT.
Divers paramètres de connexion peuvent alors être échangés, comme les identifiants du client ou encore le mode
de persistance souhaité.
Le serveur doit confirmer au client que son inscription a bien été prise en compte, soit indiquer qu’une erreur est
survenue (mauvais identifiants par ex.) en renvoyant un CONNACK accompagné d’un code de retour.
Un autre paramètre intéressant est la précision d’une durée maximale de session ( keepalive), qui indique au serveur
de considérer que la connexion est interrompue s’il ne reçoit aucune commande dans cet intervalle de temps. Pour
cela, il existe une commande PINGREQ permettant de faire savoir au serveur que le client est toujours actif, le
serveur répondra de son côté avec un PINGRESP pour indiquer au client que la connexion est toujours active.
Une fois l’enregistrement effectué, un second enregistrement sera considéré comme une erreur, ce qui implique que
l’on ne pourra pas modifier les paramètres de départ en cours de session.
Lorsque le client veut se déconnecter, il envoie au préalable une commande DISCONNECT au serveur pour lui
faire part de son intention. Dans le cas contraire, le serveur considérera la déconnexion comme anormale et agira en
conséquence (voir Testament ci-après).
b) Abonnements et Publications : Chaque message publié est nécessairement associé à un topic, ce qui
permet sa distribution aux abonnés. Les topics peuvent être organisés en hiérarchie arborescente, ainsi les
abonnements peuvent porter sur des motifs de filtrage (voir ci-après). La gestion des abonnements et publications
est simple et consiste en trois commandes essentielles:
- SUBSCRIBE Permet à un client de s’abonner à un topic (ou à un filtre), une fois abonné il recevra par la suite
toutes les publications concernant ce topic. Un abonnement définit également un niveau de qualité de service,
dont il sera question plus bas.
La bonne réception de cette commande est confirmée par le serveur par un SUBACK portant le même identifiant
de message.
- UNSUBSCRIBE Donne la possibilité d’annuler un abonnement, et ainsi ne plus recevoir les publications
ultérieures. La bonne réception de cette commande est confirmée par le serveur par un UNSUBACK portant le
même identifiant de message.
- PUBLISH Initié par un client, permet de publier un message concernant un topic, qui sera transmis par le serveur
aux abonnés éventuels (au même topic). La même commande sera envoyée par le serveur aux abonnés pour
délivrer le message.
Si la qualité de service requise est supérieure à zéro, des messages seront échangés pour confirmer la prise en
charge de la publication (voir QoS ci-après).
c) Motifs de filtrage : Afin de proposer un système de filtrage efficace sur les topics, il est possible de définir une
arborescence à l’aide du séparateur /. Deux jokers sont réservés pour représenter un et plusieurs niveaux
d’arborescence : « + » représente un niveau d’arborescence, ainsi n1/n2/n3 peut être mis en correspondance avec
divers filtres tels que n1/n2/+, n1/+/n3 ou n1/+/+. « # » représente autant de niveaux que possible, et ne peut être
utilisé qu’à la fin d’un motif de filtrage ; ainsi n1/# permettra de filtrer tous les topics dont le premier niveau est n1,
et # permet de recevoir tous les topics publiés par le broker.
d) Qualité de service : Trois niveaux de qualité de service (QoS) sont définis pour la publication des messages.
l’émetteurdéfinit le niveau de QoS de la publication de son message, le récepteur (subscriber) définit le niveau de QoS
de l’abonnement qui peut êtredifférent de celui de l’émetteur.
Ces niveaux sont mis en œuvre par des échanges supplémentaires entre l’émetteur et le récepteur. Plus la qualité
demandée est élevée, plus il faudra d’échanges pour valider une publication. Pour tous les niveaux supérieurs à zéro,
un identifiant est associé au message pour permettre son suivi. Le protocole MQTT prévoie la possibilité d’avoir au
plus 65535 messages en attente.
Université Constantine 2 –Abdelhamid mehri
Faculté des nouvelles technologies
Département du IFA / Master 1 Matière DARE

- Le niveau de QoS 0 : (atmost once) que l’on pourrait qualifier de fire-and-forget, l’émetteur se contente d’envoyer
le message, sans se soucier de savoir s’il a bien été reçu et pris en compte.
- Le niveau de QoS 1 : (at least once) garantit que le message sera envoyé au moins une fois, l’émetteur attend la
confirmation que son message a bien été reçu avant de l’effacer. Néanmoins, un message peut être dupliqué lors
de la distribution. PUBACK est un message d’acquittement pour PUBLISH avec le niveau de QoS=1.
- Le niveau de QoS 2 : (exactly once) l’émetteur attend la confirmation que le message et bien arrivé au subscriber
avant de l’effacer. PUBREC (record) est la réponse à un message PUBLISH avec QoS = 2. Le serveur ne détruit
le message que s’il reçoit une confirmation de l’émetteur qui est PUBREL (release). PUBREL est la réponse à
PUBREC. Le serveur renvoi un PUBCOMP (complete) alors l’émetteur peut détruire le message. En attendant,
toute publication portant le même identifiant est considérée comme un duplicata du message, qui ne sera donc
pas publié à nouveau par le serveur.
e) Persistance : MQTT donne au client la possibilité de choisir au moment de la connexion s’il souhaite que sa
souscription (subscription) soit conservée par le serveur une fois déconnecté. Dans ce cas, lors d’une éventuelle
reconnexion sa souscription est restaurée et le client recevra alors les messages mis en attente dont la QoS est
supérieure à zéro (les topics auxquels le client a souscrit sont conservés ainsi que le niveau de QoS qu’il a défini pour
lui-même). Il s’agit ici essentiellement d’une persistance en mémoire, qui sert surtout pour les cas où la connexion
réseau risque d’être interrompue. En revanche, il n’est pas imposé que le serveur et le client disposent d’un mécanisme
de persistance en cas d’arrêt brutal du logiciel (par exemple sur le disque), ce type de persistance nécessite des
dispositifs et des algorithmes de tolérance aux pannes dédiés, à différents niveaux du système (du niveau applicatif
 niveau physique).
f) Messages retenus : Afin de pouvoir fournir aux nouveaux Subscriber des données rapidement même lorsque le
Publisher ne publie pas à intervalles réguliers, il est possible d’indiquer au serveur de retenir une publication reçue
comme dernière publication connue pour un topic donné, qui sera transmise aux nouveaux Subscriber dès leur
souscription.
g) Testament : Lors de son enregistrement auprès du serveur, un client a la possibilité d’enregistrer un testament (WILL
message), autrement dit un message à publier par le serveur en cas de déconnexion anormale du client. Ce message
sera publié sur un topic choisi par le client.

Questions

1. Donnez la description complète de toutes les classes nécessaires pour la modélisation du protocole MQTT (remplissez
tous les compartiments).
2. Etablir le diagramme de classe correspondant à la description du protocole.
3. Elaborer le diagramme de séquence correspondant au protocole MQTT.
Recommandation : élaborer, en premier lieu, les fragments élémentaires des interactions décrites dans la section
N°5. Puis en déduire le diagramme complet.