Download - Model Based Testing des applications du protocole MQTT

Josué Melka

Model Based Testing desapplications du protocole MQTT

Mémoire de Master Recherche Informatiqueencadré par Fabrice Bouquet, Professeur des Universités

27 Septembre 2016

Table des matières

1 Introduction 4

2 Le protocole MQTT 72.1 Fonctionnement . . . . . . . . . . . . . . . . . . . . . . . . . . 8

2.1.1 Connexion et Déconnexion . . . . . . . . . . . . . . . 102.1.2 Abonnements et Publications . . . . . . . . . . . . . . 102.1.3 Qualité de service . . . . . . . . . . . . . . . . . . . . 112.1.4 Persistance . . . . . . . . . . . . . . . . . . . . . . . . 132.1.5 Messages retenus . . . . . . . . . . . . . . . . . . . . . 132.1.6 Testament . . . . . . . . . . . . . . . . . . . . . . . . . 13

2.2 Sécurité . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 142.2.1 Confidentialité . . . . . . . . . . . . . . . . . . . . . . 142.2.2 Authentification . . . . . . . . . . . . . . . . . . . . . 142.2.3 Intégrité . . . . . . . . . . . . . . . . . . . . . . . . . . 142.2.4 Gestion des droits . . . . . . . . . . . . . . . . . . . . 15

2.3 Format binaire . . . . . . . . . . . . . . . . . . . . . . . . . . 152.3.1 CONNECT . . . . . . . . . . . . . . . . . . . . . . . . 162.3.2 CONNACK . . . . . . . . . . . . . . . . . . . . . . . . 172.3.3 PUBLISH . . . . . . . . . . . . . . . . . . . . . . . . . 172.3.4 PUBACK, PUBREC, PUBREL, PUBCOMP . . . . . 182.3.5 SUBSCRIBE . . . . . . . . . . . . . . . . . . . . . . . 182.3.6 SUBACK . . . . . . . . . . . . . . . . . . . . . . . . . 192.3.7 UNSUBSCRIBE . . . . . . . . . . . . . . . . . . . . . 202.3.8 UNSUBACK . . . . . . . . . . . . . . . . . . . . . . . 202.3.9 PINGREQ, PINGRESP . . . . . . . . . . . . . . . . . 212.3.10 DISCONNECT . . . . . . . . . . . . . . . . . . . . . . 21

2.4 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21

3 Problématiques de modélisation de MQTT 233.1 Model-Based-Testing du protocole . . . . . . . . . . . . . . . 24

3.1.1 Sujet du test et observation . . . . . . . . . . . . . . . 263.1.2 Non déterminisme . . . . . . . . . . . . . . . . . . . . 26

3.2 Altération des échanges MQTT . . . . . . . . . . . . . . . . . 27

1

TABLE DES MATIÈRES 2

3.2.1 Suivi et validation des trames . . . . . . . . . . . . . . 273.2.2 Critères de transformation . . . . . . . . . . . . . . . . 283.2.3 Intégration . . . . . . . . . . . . . . . . . . . . . . . . 28

3.3 Analyse des tests . . . . . . . . . . . . . . . . . . . . . . . . . 28

4 Travail réalisé 304.1 Outils utilisés . . . . . . . . . . . . . . . . . . . . . . . . . . . 31

4.1.1 Smartesting CertifyIt . . . . . . . . . . . . . . . . . . 314.1.2 Eclipse Paho project . . . . . . . . . . . . . . . . . . . 334.1.3 Wireshark . . . . . . . . . . . . . . . . . . . . . . . . . 34

4.2 Modélisation fonctionnelle du protocole MQTT . . . . . . . . 354.2.1 Mise en œuvre . . . . . . . . . . . . . . . . . . . . . . 364.2.2 Fonctionnalités modélisées . . . . . . . . . . . . . . . . 384.2.3 Génération des tests . . . . . . . . . . . . . . . . . . . 404.2.4 Verdict . . . . . . . . . . . . . . . . . . . . . . . . . . 41

4.3 Proxy de test MQTT . . . . . . . . . . . . . . . . . . . . . . . 414.3.1 Réalisation . . . . . . . . . . . . . . . . . . . . . . . . 424.3.2 Modélisation du protocole . . . . . . . . . . . . . . . . 424.3.3 Intégration au script de test . . . . . . . . . . . . . . . 43

4.4 Bilan . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 444.4.1 Tests générés avec CertifyIt . . . . . . . . . . . . . . . 444.4.2 Modélisation du format des trames . . . . . . . . . . . 444.4.3 Exécution des test . . . . . . . . . . . . . . . . . . . . 454.4.4 Validation . . . . . . . . . . . . . . . . . . . . . . . . . 45

5 Conclusion 47

Bibliographie 49

Remerciements 51

A Codes sources (extraits) 52A.1 Suite de tests . . . . . . . . . . . . . . . . . . . . . . . . . . . 52A.2 Adaptateur pour le client MQTT . . . . . . . . . . . . . . . . 54A.3 Modélisation binaire des trames . . . . . . . . . . . . . . . . . 55

B Log des tests exécutés 57

C Extraits de l’annexe B de la norme MQTT 64

Table des figures

1.1 IoT protocol stack . . . . . . . . . . . . . . . . . . . . . . . . 5

2.3 Format d’un paquet CONNECT . . . . . . . . . . . . . . . . 162.4 Format d’un paquet CONNACK . . . . . . . . . . . . . . . . 172.5 Format d’un paquet PUBLISH . . . . . . . . . . . . . . . . . 182.6 Format d’un paquet PUB[ACK/REC/REL/COMP] . . . . . 182.7 Format d’un paquet SUBSCRIBE . . . . . . . . . . . . . . . 192.8 Format d’un paquet SUBACK . . . . . . . . . . . . . . . . . 202.9 Format d’un paquet UNSUBSCRIBE . . . . . . . . . . . . . . 202.10 Format d’un paquet UNSUBACK . . . . . . . . . . . . . . . . 212.11 Format d’un paquet PING[REQ/RESP] . . . . . . . . . . . . 212.12 Format d’un paquet DISCONNECT . . . . . . . . . . . . . . 21

4.4 Processus du test de MQTT basé sur les modèles . . . . . . 354.5 Modélisation UML du protocole MQTT . . . . . . . . . . . . 364.8 Architecture du proxy de test MQTT . . . . . . . . . . . . . 424.9 Notre processus du test pour MQTT . . . . . . . . . . . . . 43

3

Chapitre 1

Introduction

Les objets connectés se démocratisent de plus en plus, le cabinet d’ana-lyse Gartner estimant leur nombre actuel à plusieurs milliards d’unités, etprédisant que leur nombre en 2020 pourra atteindre 25 milliards [5].

La fiabilité des produits, les questions d’interopérabilité et les failles desécurité sont des problèmes encore très largement rencontrés dans ce do-maine, ce qui freine l’émergence du marché. De par leur nature, les objetsconnectés forment des systèmes complexes qui rendent ces problèmes à lafois plus cruciaux et plus difficiles à appréhender.

Pouvoir certifier efficacement ces produits apparait donc comme une né-cessité majeure, alors même que la diversité et la quantité de l’offre ne cessede croitre.

Le test est sans doute l’une des techniques de validation la plus à mêmede répondre à ce besoin. Malgré le fait qu’il ne puisse apporter de garantieabsolue sur l’absence d’imperfection, c’est un moyen efficace et relativementpeu coûteux pour apporter un certain degré de confiance sur un système.

Toutefois, la mise en place de tests sur une gamme de produits aussidiversifiée n’est pas sans poser des problèmes d’échelle. En effet, validerchaque composant peut nécessiter un grand nombre de cas de test pourfournir une couverture suffisante, et il faut une certaine expertise pour définirdes cas de test pertinents.

La méthodologie du test dirigé par les modèles offre sur ce terrain unesolution intéressante : une fois le système à tester modélisé, la génération descas de tests est automatisable et configurable. Ainsi l’on peut se contenterd’établir un modèle de test, et de le faire évoluer en fonction des besoins.

Toutefois, la complexité inhérente des systèmes connectés impose d’étu-dier soigneusement la modélisation que l’on va adopter pour générer destests. Nous avons voulu approfondir cette question en expérimentant l’ap-plication du model based testing à une problématique concrète.

4

CHAPITRE 1. INTRODUCTION 5

L’un des aspects essentiels d’une architecture IoT est celui de la commu-nication entre les divers composants du système global. Il existe bien sûrde multiples moyens de connecter et de faire communiquer les composantsen question (un aperçu des différentes couches de communication couram-ment employés est donné Figure 1.1), mais on assiste dans ce domaine àl’émergence de certains protocoles mieux adaptés que d’autres pour remplirce besoin.

Figure 1.1 – IoT protocol stack - Source : [13]

Ainsi, avec son modèle Publish/Subscribe et sa très grande légèreté, leprotocole MQTT est actuellement considéré comme l’un des candidats lesplus sérieux pour assurer le transport des données au sein des architecturesIoT [10]. Déjà largement utilisé – c’est par exemple le protocole fourni parla plateforme Amazon Webservices IoT 1, on en trouve de nombreuses im-plémentations dans divers langages de programmation, dont beaucoup sontopen-source.

Nous avons considéré ce protocole comme étant à la fois suffisammentsimple et intéressant pour constituer l’objet de notre expérimentation, qui

1. http://docs.aws.amazon.com/iot/latest/developerguide/what-is-aws-iot.html

http://docs.aws.amazon.com/iot/latest/developerguide/what-is-aws-iot.html

http://docs.aws.amazon.com/iot/latest/developerguide/what-is-aws-iot.html

CHAPITRE 1. INTRODUCTION 6

portera donc sur la mise en œuvre de tests basés sur les modèles afin devalider le support du protocole MQTT par des objets connectés.

Comme objectif de cette étude, nous avons souhaité analyser les probléma-tiques qui découlent de la mise en œuvre de tels tests, et si possible proposerles solutions qui nous semblent adaptées et généralisables.

Dans le Chapitre 2, nous présentons en détail à partir de sa spécificationle fonctionnement de MQTT ainsi que les différents aspect susceptibles d’êtremodélisés et testés.

Au Chapitre 3, nous discutons des implications de ce fonctionnement surla modélisation d’un système MQTT, et tentons de trouver des solutionsréalisables aux problèmes que nous avons rencontrés.

Enfin, le Chapitre 4 exposera notre expérimentation de modélisation duprotocole et ses résultats, ainsi que les outils utilisés et ceux qui ont dû êtrecréés pour l’occasion.

Chapitre 2

Le protocole MQTT

MQ Telemetry Transport est un protocole de messaging basé sur le pu-blish/subscribe à la fois extrêmement simple et léger, lui permettant ainsid’être utilisable à partir d’un matériel de très faible puissance, ainsi que àtravers des réseaux à forte latence voire peu fiables.

Initialement créé en 1999 par Andy Stanford-Clark (IBM) et Arlen Nip-per (Eurotech), le protocole est alors pensé pour alimenter les systèmes detélémesure, et est connu à l’origine sous le nom de MQ Integrator SCADADevice Protocol [11].

Par la suite, son code source est donné en 2011 au projet Eclipse Paho,et le protocole est standardisé par l’OASIS en 2014 dans sa version 3.1.1. Ildevient un standard ISO (ISO/IEC 20922) en 2016.

Aujourd’hui, avec l’essor de l’IoT, MQTT suscite un intérêt grandissant,dont l’on peut se rendre compte en observant l’évolution du nombre derecherches pour MQTT sur Google Trends (Figure 2.1).

Les principales caractéristiques de MQTT sont les suivantes :— Emploie le pattern publish/subscribe, permettant une distribution des

messages un-à-plusieurs, ainsi que le découplage des applications.— 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 :

1. At most once2. At least once3. Exactly once

— Volume de données échangées extrêmement réduit, limitant ainsi letrafic réseau généré.

— Un mécanisme de notification en cas de déconnexion abrupte d’unclient.

7

CHAPITRE 2. LE PROTOCOLE MQTT 8

Figure 2.1 – Google Trends pour MQTT (01/08/2016)

Les qualités intrinsèques de MQTT font de lui un excellent candidat pourles communications au sein de l’Internet des Objets [10], mais il a égalementété utilisé avec succès par Facebook pour être au cœur de leur système demessagerie, un choix dicté par la performance [16].

Actuellement, un autre protocole nommé MQTT-SN (MQTT for SensorNetworks) est en cours de développement, afin de pallier aux contraintes decertains hardwares particulièrement limités tout en garantissant une com-patibilité avec MQTT, mais ce protocole ne sera pas étudié ici.

La norme MQTT – dont nous fournissons un extrait des principales exi-gences en Annexe C – décrit le comportement attendu des serveurs (brokers)et clients MQTT, ainsi que les détails du format binaire employé pour leséchanges. La suite de ce chapitre synthétisera l’essentiel de cette norme afinde mieux appréhender la question de la modélisation par la suite.

Nous expliquons en détail le fonctionnement du protocole MQTT ensection 2.1.

La partie suivante (section 2.2) sera consacrée à l’exposé des aspects desécurité pris en compte par le protocole.

Enfin, le format binaire défini par la norme pour les paquets MQTT seraétudié dans la dernière partie (section 2.3).

2.1 FonctionnementLe fonctionnement de MQTT repose sur le pattern d’échange de mes-

sages désormais bien connu sous le nom de publish/subscribe, ou PUB/SUB.


Ce pattern consiste à organiser les messages par sujets (topics) et à gé-rer leur distribution selon le principe d’abonnement. Ainsi, toute applicationpeut publier ses messages sur les topics de son choix, tandis que les applica-tions intéressées par les messages d’un topic donné peuvent s’abonner pourrecevoir tous les nouveaux messages publiés sur ce topic.

Dans le cas d’un PUB/SUB broker-based comme MQTT, un serveur(généralement nommé broker) fait office d’intermédiaire entre les clients quipublient et ceux qui s’abonnent. Ceci afin de découpler les publishers et lessubscribers, qui n’ont besoin que de connaitre le broker pour fonctionner.

Gestion des erreurs

La plupart des erreurs, sauf celles qui ont une valeur informative im-portante pour le client (typiquement certaines erreurs à la connexion quisont signalées par un code de retour) sont soit ignorées, soit provoquentl’abandon de la connexion par l’autre partie.

Ce comportement rend évidement l’implémentation du protocole plussimple, mais le diagnostic d’une erreur est dès lors plus difficile à établirdans bien des cas.

Topologies courantes

Le standard ne définit pas de topologie particulière d’utilisation, la plussimple étant celle avec un seul broker et un certain nombre de clients, quipeut finir par poser des problèmes de passage à l’échelle.

D’autres organisation restent évidement possible, avec en particulier lessystèmes à base de bridge dans lesquels plusieurs brokers sont utilisés, chacunétant client des autres brokers, comme sur la Figure 2.2.

Pour la validation d’objets employant ce protocole, on pourra sans doutese limiter à la topologie la plus basique.

Figure 2.2 – Exemples de topologies MQTT [7]


2.1.1 Connexion et Déconnexion

MQTT se sert de connexions persistantes entre les clients et le broker,et exploite pour cela les protocoles de réseau garantissant un bon niveau defiabilité comme TCP.

Avant de pouvoir envoyer des commandes de contrôle, un client doit aupréalable s’enregistrer auprès du serveur, ce qui se fait avec la commandeCONNECT 1.

Divers paramètres de connexion peuvent alors être échangés, comme lesidentifiants du client ou encore le mode de persistance souhaité. Le serveurdoit confirmer au client que son inscription a bien été prise en compte,soit indiquer qu’une erreur est survenue (mauvais identifiants par ex.) enrenvoyant un CONNACK accompagné d’un code de retour.

Un autre paramètre intéressant est la précision d’une durée maximale desession (keepalive), qui indique au serveur de considérer que la connexion estinterrompue s’il ne reçoit aucune commande dans cet intervalle de temps.Pour cela, il existe une commande PINGREQ permettant de faire savoirau serveur que le client est toujours actif, le serveur répondra de son cotéavec un PINGRESP pour indiquer au client que la connexion est toujoursactive.

Une fois l’enregistrement effectué, un second enregistrement sera consi-déré comme une erreur, ce qui implique que l’on ne pourra pas modifier lesparamètres de départ en cours de session.

Lorsque le client veut se déconnecter, il envoie au préalable une com-mande DISCONNECT au serveur pour lui faire part de son intention.Dans le cas contraire, le serveur considérera la déconnexion comme anor-male et agira en conséquence (cf. 2.1.6).

2.1.2 Abonnements et Publications

Chaque message publié est nécessairement associé à un sujet, ce quipermet sa distribution aux abonnés. Les sujets peuvent être organisés enhiérarchie arborescente, ainsi les abonnements peuvent porter sur des motifsde filtrage que nous détaillerons plus loin.

La gestion des abonnements est très simple et consiste en trois com-mandes essentielles :SUBSCRIBE Permet à un client de s’abonner à un sujet (ou à un filtre),

une fois abonné il recevra par la suite toutes les publications concer-nant ce sujet. Un abonnement définit également un niveau de qualitéde service, dont il sera question plus bas (section 2.1.3).

1. Ici, le terme de connexion ne doit pas être confondu avec la connexion TCP (ouéquivalent) sous-jacente, c’est pourquoi j’ai préféré le terme d’enregistrement.


La bonne réception de cette commande est confirmée par le serveurpar un SUBACK portant le même identifiant de packet.

UNSUBSCRIBE Donne la possibilité d’annuler un abonnement, et ainsine plus recevoir les publications ultérieures.La bonne réception de cette commande est confirmée par le serveurpar un UNSUBACK portant le même identifiant de packet.

PUBLISH Initié par un client, permet de publier un message qui seratransmis par le serveur aux abonnés éventuels. La même commandesera 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 messagesseront échangés pour confirmer la prise en charge de la publication (cepoint sera détaillé ci-après).

Motifs de filtrage

Afin de proposer un système de filtrage efficace sur les sujets, il estpossible de définir une arborescence à l’aide du séparateur /. Deux jokerssont 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 oun1/+/+.

— # 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 tousles sujets dont le premier niveau est n1, et # permet de recevoir tousles sujets publiés par le broker 2.

2.1.3 Qualité de service

Comme nous l’avons vu plus haut, trois niveaux de qualité de service(QoS) sont définis pour la publication des messages, qui sont eux mêmerégis par deux facteurs : le niveau de QoS de la publication qui définit leniveau maximal pour la publication, et le niveau de QoS de l’abonnementqui permet au client de réduire ce niveau le cas échéant.

Ces niveaux sont mis en œuvre par des échanges supplémentaires entrel’expéditeur et le récepteur, et plus la qualité demandée est élevée, plus ilfaudra d’échanges pour valider une publication.

Pour tous les niveaux supérieurs à zéro, un identifiant est associé aumessage pour permettre son suivi, MQTT prévoyant la possibilité d’avoirau plus 65535 messages en attente (l’identifiant de message tenant sur 16bits).

2. A l’exception des sujets spéciaux commençant par $


Au niveau de qualité le plus bas (at most once), que l’on pourrait qualifierde fire-and-forget, l’expéditeur se contente d’envoyer le message, sans sesoucier de savoir s’il a bien été reçu et pris en compte. Le diagramme deséquence est donc le suivant :

Client Broker

PUBLISH

msc QoS 0

Le niveau 1 de qualité de service (at least once) garantit que le messagesera envoyé au moins une fois, car l’expéditeur attend la confirmation queson message a bien été reçu avant de l’effacer. Néanmoins, un message peutêtre dupliqué lors de la distribution dans certaines situations.

Client Broker

PUBLISH

PUBACK

msc QoS 1

Au niveau 2 de qualité de service (exactly once), le récepteur attend laconfirmation que sa réponse est bien arrivée a l’expéditeur, et considère enattendant toute publication portant le même identifiant comme un duplicatadu message, qui ne sera donc pas publié à nouveau.


Client Broker

PUBLISH

PUBREC

PUBREL

PUBCOMP

msc QoS 2

2.1.4 Persistance

MQTT donne au client la possibilité de choisir au moment de la connexions’il souhaite que sa session soit conservée par le serveur même une fois décon-necté. Dans ce cas, sa session sera restaurée lors d’une éventuelle reconnexionet le client recevra alors les messages mis en attente.

Les données de session sont tout d’abord les différents sujets auxquelsil s’est abonné, mais aussi les échanges qui n’ont pu se terminer avant ladéconnexion, ainsi que les messages de QoS supérieure à zéro qui parviennentau broker alors que le client est déconnecté.

Il s’agit ici essentiellement d’une persistance en mémoire, qui sert surtoutpour 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 depersistance en cas d’arrêt brutal du logiciel (par exemple sur le disque).

2.1.5 Messages retenus

Afin de pouvoir fournir aux nouveaux abonnés des données rapidementmême lorsque le producteur des données ne publie pas à intervalles réguliers,il est possible d’indiquer au serveur de retenir une publication reçue commedernière publication connue pour un sujet donné, qui sera transmise auxnouveaux abonnés dès leur inscription.

2.1.6 Testament

Lors de son enregistrement auprès du serveur, un client a la possibilitéd’enregistrer un testament, autrement dit un message à publier par le serveuren cas de déconnexion anormale de sa part. Ce message sera publié sur untopic choisi par le client.


2.2 SécuritéLa sécurité d’un protocole de communication est souvent primordiale

pour nombre d’applications.MQTT offre certaines options basiques pour permettre de sécuriser les

applications utilisant ce protocole, et nous verrons que le protocole est suf-fisamment souple pour intégrer d’autres mécanismes de sécurité selon lesbesoins.

Par ailleurs, la possibilité d’utiliser une connexion TLS/SSL permet d’ap-porter certaines garanties au niveau de la connexion, comme l’authentifica-tion du serveur, la confidentialité et l’intégrité des données échangées.

Au final, peu d’aspects de sécurité sont directement gérés par le proto-cole, sans doute pour garder un protocole le plus simple possible.

2.2.1 Confidentialité

La confidentialité offerte par SSL impose un certain surcoût en termesde puissance de calcul, qui n’est pas forcément disponible. Par ailleurs, ilexiste des cas ou SSL ne peut suffire à garantir le degré de confidentialitérequis, par exemple si le client ne souhaite pas que le serveur ou d’autresclients non autorisés puissent avoir accès à des données sensibles.

Dans de tels cas, il est possible d’avoir recours au cryptage des mes-sages, qui seront alors transmis tels quels, et décryptés uniquement par lesdestinataires autorisés.

2.2.2 Authentification

Optionnelle, l’authentification des clients est rendue possible au niveaudu protocole par les options username et password lors du CONNECT.Bien sûr, ceci impose que le broker supporte cette fonctionnalité et disposedes informations nécessaires sur les clients.

Une autre possibilité est d’utiliser un certificat de client pour réaliserl’authentification au niveau du hanshake SSL.

Les autres mécanismes d’authentifications courants tels que OAuth nesont pas pris en charge.

2.2.3 Intégrité

C’est également une fonctionnalité non intégrée au protocole, mais plutôtsimple à mettre en place au niveau applicatif, et qui peut être suppléée parl’usage de SSL.


2.2.4 Gestion des droits

Il peut être nécessaire pour un broker d’attribuer des droits différents auxclients en fonction de leur identité, pour définir par exemple si un client estautorisé à maintenir une session persistante, le nombre de messages maximalqu’il peut stocker, sur quels sujets peut-il s’abonner ou publier, avec quellequalité de service, etc.

MQTT ne spécifie pas de mécanisme de gestion des droits, mais chaqueimplémentation de broker est libre de fournir son propre mécanisme.

Toutefois, les options dont dispose le broker pour refuser l’action d’unclient ne sont pas très nombreuses, par exemple :— refuser un abonnement est rendu possible en renvoyant un code d’er-

reur pour le filtre en question, mais ce code peut avoir d’autres signi-fications ;

— il n’est pas possible d’indiquer qu’une publication est interdite, lesseuls choix possibles sont soit de couper la connexion, soit d’ignorersilencieusement le message.

2.3 Format binaireDans cette section, nous définissons le format binaire des paquets spécifié

par la norme MQTT. Lorsqu’un paquet ne respecte pas le format requis, laseule option possible (sauf indication contraire) est l’abandon pur et simplede la connexion.

Les chaines de caractères (notamment les sujets de publication et les filtresd’abonnements) doivent toutes être encodées en utf8, et préfixées par leurlongueur sur deux octets, ces chaines sont donc limitées à une longueur de216 − 1 = 65535 octets.

Entête fixe

Tous les packets MQTT commencent par un format d’entête fixe, conte-nant le code de commande MQTT (sur 4 bits), un champs de 4 bits et lalongueur du reste du paquet (remaining length). Cet entête est parfois suivid’un entête variable en fonction de la commande.

01234567

Control Packet Type Reserved

Remaining length...

}1 to 4bytes


Une particularité de ce champs remaining length est qu’il est de longueurvariable, et peut utiliser de 1 à 4 octets en fonction de la taille encodée :— en dessous de 27 octets, la longueur tient sur un octet ;— en dessous de 214 octets, la longueur tient sur deux octets ;— en dessous de 221 octets, la longueur tient sur trois octets ;— enfin, jusqu’à 228 octets, la longueur tient sur quatre octets.La taille maximale d’un paquet MQTT est donc de 256 Mo.

2.3.1 CONNECT

L’entête de CONNECT dans la version 3.1.1 se présente sous la formesuivante :

Figure 2.3 – Format d’un paquet CONNECT

01234567

Connect (1) 0

Remaining length...

fixedheader

length=4

’M’

’Q’

’T’

’T’

protocolname

level=4

user pass willretain

will qos will clean 0}flags

keepalive

length

client id (utf8, optional)hhhhhhhhhhhhhhhhhhh

hhhhhhhhhhhhhhhhhhh

clientidentifier

...}options


Tout d’abord le nom du protocole (préfixé par sa taille), puis le niveaudu protocole, des flags indiquant la présence ou non de paramètres option-nels ainsi que la persistance de la session (clean indique que la session estnon persistante, et constitue en même temps une directive pour effacer uneéventuelle session existante), et enfin la valeur du keepalive.

Le corps du message est composé de l’identifiant du client (chaine utf8préfixée par sa longueur, pouvant être vide depuis MQTT 3.1.1), suivi par lesparamètres optionnels dans un ordre défini : le sujet et le corps du messagede testament, le nom d’utilisateur et son mot de passe.

2.3.2 CONNACK

L’entête duCONNACK est constitué d’un bit pour indiquer si le brokerpossède déjà une session pour ce client, dans le cas où le client demande àrestaurer une session existante, et d’un code de retour sur un octet (seulsles codes de 0 à 5 étant actuellement définis).

Figure 2.4 – Format d’un paquet CONNACK

01234567

Connack (2) 0

Remaining length (2)

}fixedheader

SP

Connect return code

2.3.3 PUBLISH

Un paquet PUBLISH contient les valeurs DUP, QoS et Retain dans sonentête fixe, suivi par le sujet (taille puis chaine de caractères obligatoirementnon nulle), le packet identifier si le QoS est supérieur à zero, puis enfin lecorps du message, éventuellement vide.


Figure 2.5 – Format d’un paquet PUBLISH

01234567

Publish (3) DUP QoS retain

Remaining length...

fixedheader

topic length

topic name (utf8)hhhhhhhhhhhhhhhhhhh

hhhhhhhhhhhhhhhhhhh

1 to216 − 1bytes

packet identifier (optional)

payload (binary)hhhhhhhhhhhhhhhhhhh

hhhhhhhhhhhhhhhhhhh

0 to 228

bytes

2.3.4 PUBACK, PUBREC, PUBREL, PUBCOMP

Tous ces paquets ont la même structure, seules les valeurs du code decommande et du champs Reserved peuvent varier.

Figure 2.6 – Format d’un paquet PUB[ACK/REC/REL/COMP]

01234567

Control type (4-7) Reserved


}fixedheader

packet identifier

2.3.5 SUBSCRIBE

Un paquet SUBSCRIBE comprend un identifiant pour la réponse, puisune liste de souscriptions d’au moins un élément. La structure d’une sous-


cription est composée d’un filtre (longueur et chaine de caractères) et de laqualité de service demandée.

Figure 2.7 – Format d’un paquet SUBSCRIBE

01234567

Subscribe (8) 2

Remaining length...

fixedheader

packet identifier

filter length

topic filter (utf8)hhhhhhhhhhhhhhhhhhh

hhhhhhhhhhhhhhhhhhh

QoS...

1 to nsubscriptions

2.3.6 SUBACK

Dans un paquet SUBACK, le broker répond avec le même identifiantde paquet, puis retourne les code de retour dans le même ordre que lessouscriptions du paquet SUBSCRIBE correspondant.

Ces codes de retour correspondent à la qualité de service garantie par lebroker (qui peut être inférieure à celle initialement demandée), ou le coded’erreur 0x80 en cas de problème.


Figure 2.8 – Format d’un paquet SUBACK

01234567

Suback (9) 0

Remaining length...

fixedheader

packet identifier

return code...

} 1 to nreturncodes

2.3.7 UNSUBSCRIBE

UNSUBSCRIBE ressemble beaucoup à SUBSCRIBE, à ceci prèsque le client ne spécifie pas de qualité de service.

Figure 2.9 – Format d’un paquet UNSUBSCRIBE

01234567

Unsubscribe (10) 2

Remaining length...

fixedheader

packet identifier

filter length

topic filter (utf8)hhhhhhhhhhhhhhhhhhh

hhhhhhhhhhhhhhhhhhh

...

1 to nsubscriptions

2.3.8 UNSUBACK

UNSUBACK sert de confirmation pourUNSUBSCRIBE, et contientsimplement l’identifiant de paquet de la requête correspondante.


Figure 2.10 – Format d’un paquet UNSUBACK

01234567

Unsuback (11) 0


}fixedheader

packet identifier

2.3.9 PINGREQ, PINGRESP

Ces deux paquets sont très simples, et sont constitués uniquement del’entête fixe du protocole, tenant ainsi sur deux octets.

Figure 2.11 – Format d’un paquet PING[REQ/RESP]

01234567

Control type (12-13) 0


}fixedheader

2.3.10 DISCONNECT

Sert à indiquer au broker l’intention du client de se déconnecter, et com-porte uniquement l’entête fixe.

Figure 2.12 – Format d’un paquet DISCONNECT

01234567

Disconnect (14) 0


}fixedheader

2.4 ConclusionNous avons vu que MQTT est un protocole tout à la fois minimaliste et

très simple à mettre en œuvre (en particulier du coté client). Malgré tout,il reste suffisamment souple et extensible pour suffire aux besoins d’un bonnombre d’applications, et est donc particulièrement adapté au contexte del’IoT.

C’est la raison pour laquelle nous avons choisi ce protocole pour expé-rimenter l’approche du test dirigé par les modèles, avec pour objectif de


réaliser une modélisation du protocole capable de s’assurer des propriétésque l’on doit être en mesure d’attendre des futurs « objets » d’Internet :conformité avec la norme, interopérabilité des différentes implémentations,respect des exigences de sécurité et tolérance aux erreurs.

Chapitre 3

Problématiques demodélisation de MQTT

Modéliser un protocole afin d’en tester les applications est une opéra-tion qui présente un intérêt évident dès lors que les tests engendrés vontpermettre d’apporter un certain degré de confiance aux produits testés.

Plus le protocole est couramment employé et les tests généralisables (ie.applicables au plus grand nombre de produits), plus l’intérêt de ce type d’ap-proche grandit. En effet, le coût de développement du test peut se trouverélevé, mais il sera compensé par son potentiel de réutilisation pour tous lesproduits ainsi que dans le temps 1.

Idéalement, on aimerait disposer d’un moyen de formaliser simplementles exigences qui décrivent le protocole, avec un outil permettant de trans-former ce formalisme en suite de tests garantissant une bonne couverturede ces exigences. Une bonne modélisation devrait également permettre derépondre à des objectifs divers, comme s’assurer des propriétés de robus-tesse des implémentations, d’interopérabilité entre les différents produits,de sécurité, etc.

Malheureusement, atteindre un tel niveau d’automatisation est loin d’êtretrivial. Nous avons voulu d’abord explorer la réalisation d’un banc de testbasé sur les modèles spécifique au protocole MQTT, avec l’objectif d’iden-tifier et de résoudre les problématiques soulevées, et, dans le cas où cetexercice se trouverait concluant, d’en généraliser les conclusions à d’autresprotocoles sinon à d’autres approches.

Nous avons déjà montré au Chapitre 2 que les exigences de la normeMQTT peuvent être divisées en deux parties, avec d’une part l’aspect fonc-

1. On pourra consulter la page du MQTT Interop Testing Day (https://wiki.eclipse.org/Paho/MQTT_Interop_Testing_Day) pour trouver des détails sur la métho-dologie adoptée pour les tests d’interopérabilité entre les diverses implémentations duprotocole.

23

https://wiki.eclipse.org/Paho/MQTT_Interop_Testing_Day

https://wiki.eclipse.org/Paho/MQTT_Interop_Testing_Day

CHAPITRE 3. PROBLÉMATIQUES DE MODÉLISATION DE MQTT24

tionnel du protocole, et d’autre part l’aspect de bas niveau concernant ladéfinition du format binaire des échanges.

En analysant plus en détail la norme MQTT, on s’aperçoit d’ailleursque certaines exigences ne sont pas accessible depuis l’interface habituelledes clients et nécessitent un accès que l’on pourrait qualifier de bas niveaupour être vérifiées (voir extrait en Table 3.1, les exigences de haut niveausont indiquées colonne + et celles de bas niveau colonne −).

Il nous a donc semblé judicieux de définir dans un premier temps unmodèle abstrait du protocole qui ne prenne pas en compte tous les détailsde bas niveau de la norme, et visant à activer les divers comportementspossibles afin de tester la partie fonctionnelle du protocole.

Par la suite, afin de valider le format des commandes échangées, ainsique de tester le comportement des différents composants et implémentationsMQTT en cas d’altération des paquets échangés, nous avons imaginé unsystème permettant d’analyser et de modifier les trames à la volée.

Dans la première partie de ce chapitre (section 3.1) nous présentons lesproblèmes soulevés par la modélisation abstraite envisagée et, le cas échéant,les solutions proposées.

Puis dans la seconde partie (section 3.2), nous traitons de la mise aupoint du test basé sur les fautes de protocole et altérations des échanges,ainsi que de son intégration au sein de l’environnement de test.

Enfin, dans la dernière partie (section 3.3), nous conclurons par unediscussion sur le suivi des tests qui s’est avéré particulièrement délicat dansnotre contexte.

3.1 Model-Based-Testing du protocolePour la modélisation des aspects fonctionnels du protocole, nous avons

utilisé le paradigme de modélisation state-based à l’aide d’une modélisationUML des différents composants et leurs opérations associées, ainsi que decontraintes Pre/Post en OCL sur les différentes opérations du modèle per-mettant de garantir les invariants définis par la norme MQTT.

L’objectif de cette étape étant de formaliser les aspects fonctionnels duprotocole, puis d’employer un moteur de génération de tests afin de trans-former ce formalisme en suites de test visant à activer les différents compor-tements possibles pour le protocole.

Nous n’entrerons pas ici dans les détails de la modélisation effectuée (cesera fait section 4.2), mais nous exposerons dans un premier temps les prin-cipales problématiques que nous avons identifiées comme liées au contexteparticulier du test des applications MQTT.


Table 3.1 – Analyse du « niveau » de quelques exigences de la norme MQTT

Number Normative statement + -1.5.3-2 A UTF-8 encoded string MUST NOT include an encoding of

the null character U+0000.X

2.2.2-1 Where a flag bit is marked as “Reserved” in Table 2.2, itMUST be set to the value listed in that table.

X

3.1.2-1 If the protocol name is incorrect the Server MAY disconnectthe Client, or it MAY continue processing the CONNECTpacket in accordance with some other specification.

X

3.1.2-4 If CleanSession is set to 0, the Server MUST resume commu-nications with the Client based on state from the current Ses-sion. If there is no Session associated with the Client identifierthe Server MUST create a new Session.

X

3.1.2-22 If the User Name Flag is set to 0, the Password Flag MUSTbe set to 0.

X

3.1.3-7 If the Client supplies a zero-byte ClientId, the Client MUSTalso set CleanSession to 1.

3.3.1-4 A PUBLISH Packet MUST NOT have both QoS bits set to 1. X3.3.2-2 The Topic Name in the PUBLISH Packet MUST NOT contain

wildcard characters.X

3.8.4-1 When the Server receives a SUBSCRIBE Packet from a Client,the Server MUST respond with a SUBACK Packet.

X

3.9.3-2 SUBACK return codes other than 0x00, 0x01, 0x02 and 0x80are reserved and MUST NOT be used.

X

4.3.1-1 In the QoS 0 delivery protocol, the Sender MUST send a PU-BLISH packet with QoS=0, DUP=0.

X X

4.3.2-1 In the QoS 1 delivery protocol, the Sender MUST send a PU-BLISH Packet containing this Packet Identifier with QoS=1,DUP=0. MUST treat the PUBLISH Packet as "unacknowled-ged" until it has received the corresponding PUBACK packetfrom the receiver.

X X

4.3.2-2 In the QoS 1 delivery protocol, the Receiver MUST respondwith a PUBACK Packet containing the Packet Identifier fromthe incoming PUBLISH Packet.

X

4.3.3-1 In the QoS 2 delivery protocol, the Sender MUST send a PU-BLISH packet containing this Packet Identifier with QoS=2,DUP=0. MUST treat the PUBLISH packet as "unacknowled-ged" until it has received the corresponding PUBREC packetfrom the receiver. MUST send a PUBREL packet when it re-ceives a PUBREC packet from the receiver. MUST treat thePUBREL packet as "unacknowledged" until it has received thecorresponding PUBCOMP packet from the receiver.

X X

4.3.3-2 In the QoS 2 delivery protocol, the Receiver MUST respondwith a PUBREC containing the Packet Identifier from theincoming PUBLISH Packet. MUST respond to a PUBRELpacket by sending a PUBCOMP packet containing the samePacket Identifier as the PUBREL.

X

4.4.0-1 When a Client reconnects with CleanSession set to 0, boththe Client and Server MUST re-send any unacknowledged PU-BLISH Packets (where QoS > 0) and PUBREL Packets usingtheir original Packet Identifiers.

X

4.7.1-1 The wildcard characters MUST NOT be used within a TopicName.

X

4.7.3-1 All Topic Names and Topic Filters MUST be at least onecharacter long.

X


3.1.1 Sujet du test et observation

Rappelons ici que la définition du protocole englobe le comportementde différents acteurs tels que le broker et les clients, qui forment un en-semble d’interactions possibles très riche. Ainsi le système sous test (SUT)comprendra généralement tous les acteurs dont on cherche à valider le com-portement, tandis que nous définissons ici comme « sujet » du test le ou lesproduits qui sont visés par un test en particulier.

Pour notre part, nous avons opté pour une modélisation globale du sys-tème sans adopter de point de vue particulier (et notamment sans faire dedistinction selon les différents types de composants testés), ce qui pose laquestion lors de l’exécution d’une suite de tests de savoir quel est le compo-sant testé et comment l’observer en particulier.

En effet, pour des raisons d’interface, les composants directement ma-nipulés lors d’un test ne seront pas nécessairement ceux dont on chercheà valider le comportement. Ceci se traduit par une plus grande complexitédans la mise en place de points d’observation, qui doivent se situer au niveaumacroscopique du système (par ex. en analysant les échanges réseau dansleur ensemble, et pas seulement coté broker ou client).

Pour résoudre la question de l’identification des composants fautifs, onutilisera autant que possible une implémentation de référence pour les partiesqui ne sont pas directement concernées par le test, mais il nous a égalementparu souhaitable que le suivi des tests soit capable de distinguer quel est lecomposant responsable de l’échec d’un test en particulier.

3.1.2 Non déterminisme

Il nous est vite apparu que les séquences d’actions qui font ici l’objet dutest (l’échange de messages entre différentes parties au sein du réseau) sontessentiellement non déterministes.

En effet, l’aspect asynchrone des échanges fait que l’on ne peut pas tou-jours contrôler l’ordre d’envoi et/ou de distribution des messages, et plus ily a d’acteurs impliqués et donc de messages échangés entre les différentessources, plus l’incertitude quant à l’ordre des actions augmente.

Par ailleurs, les sujets du test (i.e. les différentes implémentations declients et brokers MQTT) ne proposent pas toujours une interface permet-tant de contrôler finement ce qui se passe au niveau du protocole, ce quipeut avoir pour effet d’aggraver l’incertitude en question.

En dernier lieu, certaines exigences de la norme MQTT concernant lebroker sont optionnelles (par ex. le support ou non de tous les niveaux deQoS), et donnent lieu à différents comportements possibles dans certainscas.

Cet aspect des choses rend le suivi du test beaucoup plus complexe,les solutions permettant de contrôler l’exécution d’une suite de test non-


déterministe et donner un verdict étant plus délicates à mettre en œuvreque pour un test déterministe. Également, certaines configurations serontplus difficiles sinon impossibles à atteindre, du moment que l’on ne maitrisepas totalement le déroulement du test.

3.2 Altération des échanges MQTTTester uniquement des composants concrets ne permet pas nécessaire-

ment d’activer toutes les erreurs possibles, ainsi il est nécessaire de pouvoirtransmettre des trames spécialement forgées avec des erreurs afin de s’assu-rer une bonne couverture de test.

Afin de répondre à ce besoin, nous avons choisi d’ajouter un modulecapable de modifier à la volée les trames MQTT échangées entre les compo-sants sous test. Module qui peut être intercalé entre un broker MQTT et sesclients tout en restant transparent pour les différentes parties, tel un proxy.

En mode analyse, ce proxy se contenterait d’analyser les paquets quitransitent entre les différents composants, tandis qu’en mode d’injectionil permettrait de modifier les trames MQTT en prenant en compte leurstructure, ciblant ainsi avec précision les champs que l’on veut perturber etles modifications que l’on souhaite apporter.

Pour mettre au point cet outil, il faut donc modéliser la structure binairedes trames MQTT et le type des divers champs qui les constituent (cf.section 2.3), afin de pouvoir leur appliquer des modifications pertinentespour le test en fonction du type des champs altérés, de leur valeur, etc.

L’intégration de ce modèle au sein du modèle général pose toutefois unproblème qui sera discuté plus bas. Il serait également possible d’envisagerune approche plus complète, en donnant à un composant intermédiaire lapossibilité de jouer alternativement le rôle du client ou du broker MQTT, etainsi de mieux maitriser l’ensemble du test. Mais cette approche reviendraità implémenter l’ensemble du protocole uniquement à des fins de test, ce quinous a paru trop couteux et impraticable dans le cas général.

3.2.1 Suivi et validation des trames

Un des avantages apportés par l’introduction de ce type de proxy estqu’il autorise un suivi précis des trames échangées au niveau du réseau sansavoir à utiliser un outil spécialisé comme un sniffeur de réseau. Ainsi il esttrès facile d’enregistrer l’ensemble des trames échangées dans un fichier delog pour une analyse ultérieure.

On peut également outiller le suivi des trames MQTT en y ajoutantune validation des trames à la volée, ce qui permet de détecter facilementles composants fautifs dans l’implémentation de la partie bas niveau duprotocole.


Ainsi, il est possible de suivre les trames entrant dans le proxy et d’encontrôler la validité, tout en conservant la faculté d’appliquer des mutationsaux trames sortantes.

3.2.2 Critères de transformation

Dans une optique d’injection de données faussées, il convient d’établirdes critères de transformation pertinents pour les différents champs pré-sents dans les trames, et de disposer d’un moyen efficace pour choisir etappliquer ces transformations. Critères qui doivent être pris en compte pourla modélisation des trames du protocole si l’on veut pouvoir effectuer desmodifications intéressantes dessus.

Pour cela, le type des champs et leur valeur peuvent être exploités afin desélectionner diverses catégories de mutations. Par exemple, on peut choisirles valeurs aux limites en fonction du domaine de chaque champs, ou encorede réaliser des mutations pour altérer certaines valeurs au plus proche. Il estégalement très simple d’injecter des valeurs explicitement interdites par leprotocole pour faire du test de robustesse.

On pourra aussi décider de ne pas retransmettre une commande pourperturber l’échange entre les clients et le broker, ou encore de couper laconnexion de façon intempestive pour simuler des problèmes de réseau.

3.2.3 Intégration

L’une des difficultés liées à cette approche réside dans le fait que l’outilen question n’a pas une vision globale sur l’ensemble des échanges, et il luiest donc difficile de choisir quelles transformations appliquer sur les donnéesà un moment donné.

Il est bien sûr possible d’appliquer des transformations aléatoires (fuz-zing), mais l’on perdrait alors l’essentiel du bénéfice de la modélisation. Parailleurs, l’analyse des tests deviendrait dès lors beaucoup plus laborieuse,puisque l’on ne va pas disposer d’un oracle permettant de connaitre auto-matiquement le résultat attendu pour chaque test.

On peut également envisager des approches plus évoluées dans lesquellesle proxy serait intégré dans un système de modélisation plus général et pilotépar ce dernier. Il faut pour cela que la modélisation prenne en compte leformat binaire du protocole en question, le proxy devenant alors un simpleexécutant des séquences prévues.

3.3 Analyse des testsLa nature des problématiques évoquées plus haut complexifie largement

le processus de suivi automatisé des suites de test.


D’une part, l’aspect non déterministe pose des difficultés pour établir etvérifier le verdict de chaque cas de test, puisqu’il n’existe pas qu’une seuletrace d’exécution valide possible mais bien plusieurs. Pour pallier à cela, ilfaut donc vérifier que la trace obtenue correspond bien à l’une des tracespossibles.

Même sans cette difficulté, le résultat d’une séquence de test n’est pastoujours exprimable par un résultat précis (par ex. vérifier si tel message estbien reçu ou non), car il faut vérifier que le protocole a été respecté de bouten bout.

Pour ces raisons, il nous parait souhaitable de doter le modèle de la ca-pacité d’analyser le passage d’un test en vérifiant tout au long de l’exécutionque les invariants définis sont bien respectés, autrement dit que la trace cor-respond bien à un chemin d’exécution possible du modèle. Il ne s’agit passeulement ici de générer le test en mode online, mais bien de suivre sonexécution pas à pas à l’aide du modèle.

Le détail des commandes échangées par le protocole devrait dans la plu-part des cas constituer une trace suffisante pour effectuer ce type d’analyse.

En ce qui concerne l’idée de test à base de mutations des trames, si l’on secontente de modéliser uniquement la partie bas-niveau du protocole, il seraimpossible de prédire quelle est la réaction attendue pour une grande partiedes modifications possibles.

Pour autant, certaines transformations devraient systématiquement don-ner lieu à une coupure de la connexion, et sont donc facilement vérifiables.Pour les autres, elles peuvent être pilotées depuis un système extérieur pro-posant des modifications ciblées, soit faire l’objet d’une analyse manuelle ouse limiter à vérifier que le SUT ne tombe pas en panne (crash) à cause d’unetrame mal formée.

Chapitre 4

Travail réalisé

Une partie de notre travail de recherche a consisté en l’expérimenta-tion de l’approche de modélisation envisagée au chapitre précédent. Nousprésentons ces contributions dans ce chapitre.

Nous avons commencé par modéliser l’aspect fonctionnel de MQTT avecl’outil CertifyIt de Smartesting, qui nous a permis de construire un modèleabstrait du protocole. Notre modèle inclut la plupart des fonctionnalitéset exigences définies par la norme sous forme de contraintes, et permet degénérer des suites de test en conséquence.

Faute de temps, nous n’avons pu compléter cette modélisation, maisl’exercice devrait être pleinement réalisable.

L’outil évoqué en section 3.2 a été partiellement réalisé, à travers la mo-délisation binaire des trames du protocole et le développement du proxyMQTT envisagé.

Pour le reste, nous avons dû réviser une partie de nos ambitions à labaisse. La validation des trames à la volée a été implémentée, ainsi que lemode de fuzzing autonome, mais nous n’avons pas exploité la possibilité depiloter le proxy à partir du modèle.

Les suites de tests ont été rendues exécutables grâce à l’export des testsen python et l’écriture d’un adaptateur approprié pour un client MQTT denotre choix.

La plus grande difficulté a sans doute été l’établissement du verdict pourles cas de test. Nous nous sommes finalement contentés de générer les sé-quences de messages attendues pour chaque cas de test, qui ont fait l’objetd’un contrôle manuel.

Dans la section 4.1, nous présentons les principaux outils utilisés pour lesexpérimentations, depuis la phase de modélisation jusqu’à celle de l’analyse

30

CHAPITRE 4. TRAVAIL RÉALISÉ 31

des tests.Ensuite, à la section 4.2, nous détaillerons la modélisation de la partie

fonctionnelle du protocole avec CertifyIt, ainsi que de l’export des suites detests dans un environnement exécutable.

Dans la section 4.3 nous décrirons la mise en œuvre d’un proxy MQTTdoté de fonctionnalités adaptées à notre banc de test.

Enfin, nous dresserons le bilan de nos expérimentations en section 4.4.

4.1 Outils utilisés

4.1.1 Smartesting CertifyIt

CertifyIt est une chaine d’outils dédiée auModel-Based Testing, basée surle langage UML pour la modélisation et le langage OCL (Object ConstraintLanguage) pour l’expression des contraintes sur les modèles.

Fruit d’une collaboration entre l’institut Femto-ST et la compagnie Smar-testing, CertifyIt permet de modéliser un système sous test (SUT) et degénérer automatiquement des suites de test selon différents critères, à partirdes contraintes indiquées dans le modèle.

Figure 4.1 – CertifyIt - vue de l’éditeur UML

Le logiciel est divisé en deux parties :— un éditeur de modèles (Figure 4.1) sous la forme d’un plugin pour

Rational Software Architect Designer d’IBM (lui même reposant surEclipse), qui permet de modéliser le SUT, de définir les critères de


sélections de tests, et d’exporter le tout dans un format supporté parle générateur de tests ;

— un générateur de tests (Figure 4.2) avec différentes fonctionnalitéstelles que le suivi des exigences, des contraintes activées pour chaquetest, l’export des tests en divers formats d’exploitation (comme XML,ou encore JUnit).

Figure 4.2 – CertifyIt - vue du générateur de tests

Modélisation

La notation UML employée est un sous ensemble d’UML2, restreintaux besoins du test dirigé pas les modèles, appelé UML4MBT. La nota-tion OCL pour les contraintes est également restreinte à un sous ensembleappelé OCL4MBT.

Seuls trois types de diagrammes UML sont supportés :— les diagrammes de classes, utilisés pour modéliser les variables du sys-

tème, ainsi que les points de contrôle et d’observation ;— les diagrammes d’états-transitions, qui permettent de modéliser la dy-

namique du système ;— les diagrammes d’objets, qui permettent de définir les instances d’ob-

jets qui serviront pour le test.Les expressions OCL servent deux objectifs bien distincts :


— d’une part, à exprimer les conditions associées aux objets du modèle,en définissant les pré-conditions de certaines opérations du diagrammede classes, et les gardes sur les transitions du diagramme d’états.

— d’autre part, à formaliser le comportement du modèle en termes d’ac-tions qui vont modifier l’état du système, grâce aux post-conditionsdes opérations et aux effets des transitions.

Pour remplir ces deux rôles, la sémantique de OCL4MBT dépend ducontexte, le sens des expressions pouvant être soit déclaratif comme dans lecas d’OCL, soit exprimeront le comportement des opérations à la façon d’unlangage de programmation.

Sélection des tests

L’approche du test dirigé par les modèles emploie des critères de sélectiondivers pour dériver les cas de test à partir du modèle.

Avec CertifyIt, le critère de sélection principal consiste à activer les com-portements qui ont été modélisés (behavioral test objectives). Il est possiblede sélectionner l’ensemble des méthodes qui seront utilisés pour une suitede tests donnée (test fixtures) parmi les méthodes publiques du modèle.

D’autres critères peuvent aussi être utilisés, comme avec les test purposesqui permettent de formaliser différents scénarios que le générateur de testscherchera à satisfaire.

4.1.2 Eclipse Paho project

Le projet Paho 1 de la fondation Eclipse a pour vocation de fournir desimplémentations open-source de qualité pour les protocoles de messagingouverts et standardisés, dans le but de favoriser l’émergence de nouveauxproduits et applications liés à l’Internet des Objets.

Le projet a été initialement lancé dans le but de fournir des implémen-tations MQTT pour les plateformes embarquées, et propose aujourd’hui desclients MQTT pour différents langages de programmation.

Nous nous somme intéressés en particulier à l’implémentation pythondu projet, afin d’en étudier son code source et avec l’intention de s’en servircomme candidat au test.

paho.mqtt.python

paho.mqtt.python provient à l’origine du client python Mosquitto deRoger Light, qui l’a mis à la disposition du projet Paho et continue sondéveloppement. Le projet est actuellement disponible sur github à l’adressehttps://github.com/eclipse/paho.mqtt.python, et constitue sans doutel’implémentation open-source de référence en python.

1. https://wiki.eclipse.org/Paho

https://github.com/eclipse/paho.mqtt.python

https://wiki.eclipse.org/Paho


Dans un premier temps, nous avons étudié son fonctionnement à l’aidedu code source. Ainsi nous avons pu relever un certain nombre de bugs etd’anomalies vis-a-vis du protocole qui ont été rapportées sur le bugtrackerdu projet 2.

Ceci nous a fait prendre pleinement conscience de l’importance de pou-voir tester extensivement ces produits, qui malgré le fait d’être open-sourceet de disposer d’un bon nombre d’utilisateurs, peuvent tout de même com-porter divers bugs.

Par la suite, c’est l’implémentation que nous avons choisi d’utiliser cotéclient pour nos expérimentations, qui ont été réalisées avec le langage pythonet que nous présentons aux sections suivantes.

4.1.3 Wireshark

Wireshark est un analyseur de paquets réseau disposant d’une foule defonctionnalités avancées (en particulier un sniffer très pratique à utiliser etdes filtres), et le support de très nombreux protocoles dont MQTT 3 .

Figure 4.3 – Wireshark 2.0.5 - vue du logiciel

Ce logiciel est couramment utilisé dans le monde de l’éducation afin depermettre aux étudiants de mieux comprendre les protocoles réseau. Nous

2. https://github.com/eclipse/paho.mqtt.python/issues/created_by/yoch3. Depuis la version 1.12 du 31 Juillet 2014. A noter que MQTT-SN est également

supporté depuis la version 2.0.

https://github.com/eclipse/paho.mqtt.python/issues/created_by/yoch


l’avons exploité de deux manières, d’une part afin de mieux comprendrecertains aspects du protocole MQTT, et d’autre part pour l’analyse manuellede certains tests.

Dans la capture d’écran visible Figure 4.3, on peut voir que le filtragedu protocole MQTT est activé, la liste des paquets interceptés est visibledans le cadre du haut, et dans celui du milieu et celui du bas sont représentésle contenu du paquet sélectionné (structure détaillée et données binaires).

4.2 Modélisation fonctionnelle du protocole MQTTLe Model Based Testing suit généralement le processus suivant [15] :1. Construction du modèle de test d’après les spécifications produit, qui

doit proposer le bon niveau d’abstraction pour permettre de générerdes cas de tests en rapport avec les exigences.

2. Choix de critères de sélection de test, en fonctions des objectifs et dela politique de test. Ces critères seront transformés en spécificationssur les cas de test à générer.

3. Génération de la suite de test, éventuellement en optimisant le nombrede tests produits.

4. Exécution des tests, qui peut être manuelle ou automatisée. Il s’agittout d’abord de concrétiser les cas de test, puis d’envoyer les donnéesau SUT, et d’observer les résultats.Usuellement, on utilise un adaptateur pour cette tâche, qui sert àadapter les cas de test au SUT et les sorties du SUT à l’outil de testqui va les comparer avec le résultat attendu.

Pour notre expérimentation, le processus adopté se représente commesuit (Figure 4.4) :

Figure 4.4 – Processus du test de MQTT basé sur les modèles

— La modélisation du protocole a été effectuée en UML/OCL ;— Génération des suites de tests aux critères dits behavioral test objectives

avec l’outil CertifyIt, qui sont ensuite exportés en XML ;— Ce fichier XML nous permet de générer un script pour piloter les

tests, ainsi que le squelette du code python pour l’adaptateur, qui seracomplété manuellement pour permettre l’exécution des tests sur unecible donnée ;


— Les tests sont exécutés à l’aide script python et produisent une traced’exécution pour chaque test ;

— Les logs servent pour l’analyse des résultats du test, en les comparantavec la trace attendue par le modèle.

4.2.1 Mise en œuvre

Nous avons réalisé une modélisation de la partie fonctionnelle du proto-cole MQTT en UML/OCL à l’aide de CertifyIt (Figure 4.5). Dans ce quisuit nous retraçons les grandes lignes de cette contribution.

Figure 4.5 – Modélisation UML du protocole MQTT

Détail du modèle

Les composants UML principaux sont les classes Broker et Client, lebroker pouvant prendre en charge simultanément la connexion de plusieursclients. Chaque client connecté maintient une Session lui permettant decontrôler le transit des messages, tandis que le broker maintient une Sessionpour chaque client.


Un client peut être soit déconnecté, soit connecté au broker sans avoirinitié un échange MQTT, soit connecté avec une session en cours. Le premieraspect est géré par une relation one-to-many entre le broker et les clientsmodélisant la connexion TCP, tandis que le second aspect est géré à l’aided’un booléen indiquant que la session est commencée.

Coté broker, la gestion des identités des clients se fait à l’aide de laclasse Identifier qui représente simplement un couple login / mot de passe.Une méthode register permet de modéliser l’ajout de nouveaux couplesd’identifiants (login et mot de passe).

Quant à la gestions des abonnements, elle est gérée par le broker avecla classe Subscription, et est limitée ici au filtrage des motifs par corres-pondance exacte pour des raisons de simplicité. Lorsqu’un client envoie unedemande d’abonnement avec la méthode subscribe, le broker crée un nouvelabonnement avec l’identifiant du client, le filtre de sujet et la qualité de ser-vice requise, et l’ajoute à sa liste d’abonnements. La méthode unsubscribeprovoque à l’inverse la suppression d’un abonnement existant.

La classe Message modélise les messages véhiculés par le protocole etcontient les informations permettant de suivre l’évolution de l’état de trans-mission d’un message. Cet état est régi par un système d’états / transitionsimplicite codé dans les post-conditions OCL.

Gestion des types chaines de caractères

Le type chaines de caractères n’étant pas supporté par CertifyIt, nousl’avons substitué par des énumérations destinées à représenter des types dedonnées particuliers, comme par exemple un mot de passe.

Gestion des échanges asynchrones

Dans une première version de notre travail, l’enchainement des actionsétait réalisée par des appels de méthodes imbriqués, ce qui rendait le modèletotalement synchrone et peu satisfaisant. Il était en effet impossible de pro-voquer une seconde action avec effet de bord tout au long de l’enchainementdes actions déclenché par telle ou telle méthode (par exemple de couper laconnexion au cours d’un échange de trames servant à valider la réceptiond’un message).

C’est pourquoi, nous avons modifié le modèle initial en limitant l’en-semble des méthodes à un seul échange réseau, la suite de l’enchainementétant assurée par la méthode process_messages. Ainsi le générateur detests peut ou non employer cette méthode pour influer sur le déroulementdu test.


Annotations pour le suivi des exigences

Les post-conditions ont été documentées à l’aide du mécanisme d’anno-tation de CertifyIt afin de permettre le suivi des exigences.

Diagramme d’objets

CertifyIt requiert de créer les instances et relations nécessaires au testdans un diagramme d’objet.

Pour plus de souplesse, le modèle a été conçu pour être aussi dynamiqueque possible. Aussi, les relations n’ont pas été établies au sein du diagrammed’objets, mais sont manipulables à l’aide des méthodes définies par le modèle,ce qui permet au générateur de créer ou supprimer des relations en fonctiondes besoins.

4.2.2 Fonctionnalités modélisées

La plupart des fonctionnalités de MQTT mentionnées section 2.1 ont étémodélisées, certaines n’ayant toutefois pas pu l’être faute de temps.

Comme vu en section 2.2, peu d’aspects de sécurité sont directementpris en charge par le protocole, mais reposent plutôt sur des mécanismesconnus comme SSL ou sont relégués à des extensions non normalisées voireau domaine applicatif. Le seul point de sécurité qui a donc été introduitdans notre modèle est celui de l’authentification des clients.

Nous présentons dans ce qui suit l’essentiel des fonctionnalités modéli-sées, accompagnées de quelques illustrations concrètes.

Connexion

Les principaux aspects de l’enregistrement auprès du serveur (envoi dupaquet CONNECT et réponse) ont pu être modélisés :— toute connexion doit débuter par un CONNECT ;— pas de double CONNECT ;— gestion du renouvellement de session ;— authentification des clients ;La dimension temporelle impliquée par le keepalive n’a pas été introduite

dans le modèle car trop complexe pour un gain relativement faible (seule lescommandes PINGREQ et PINGRESP sont concernées, et leur validation nepose pas de problème particulier).

Un exemple de postcondition OCL pour la gestion du CONNECT parle broker est proposé Figure 4.6. On y trouve l’interdiction d’un doubleCONNECT ainsi que celle de restaurer une session pour un client anonyme,les autres exigences étant traitées par des méthodes auxiliaires.


Figure 4.6 – Postcondition OCL pour handle_connect()

Abonnements et Publications

Le mécanisme d’abonnement et ses différentes commandes est lui aussimodélisé :

— vérification (partielle) de la validité des sujets ;— vérification de la validité de la qualité de service requise ;— gestion des abonnements et réponse du broker ;— gestion des publications ;

Cependant, certains détails du protocole ont été simplifiés par commo-dité, notre modèle ne prenant pas en charge les abonnements multiples.

Qualité de service et Persistance

La gestion des échanges impliqués par les différentes qualités de servicea également pu être modélisée :

— support des différentes réponses : PUBACK, PUBREC, etc.— mise des messages en file d’attente de la session pour gérer les décon-

nexions ;— gestion des identifiants de paquets ;

L’aspect asynchrone des échanges a été modélisé avec l’approche détailléeen section 4.2.1. On peut voir l’essentiel du traitement asynchrone du cotéclient Figure 4.7, l’état des messages en file d’attente pouvant changer dèslors que le générateur fait appel à process_messages() 4 .

4. Il serait également possible de modifier l’état d’un seul message dans la file d’attente,mais ceci surchargerait à coup sûr le générateur.


Figure 4.7 – Postcondition de process_messages() coté client

Messages retenus et Testament

Ces deux aspects du protocole n’ont pas été modélisés par manque detemps, mais ne devraient pas poser de problème particulier.

4.2.3 Génération des tests

Afin de distinguer les différents objectifs de test, nous avons créé plusieurssuites de test avec différentes cibles : test de l’identification des clients, testdes publications de messages, etc. Pour ce faire, nous avons sélectionné pourchaque suite des sous-ensembles de fixtures utilisables parmi les méthodespubliques du modèle, ce qui laisse au générateur un choix restreint d’actionsdisponibles pour dériver les cas de tests.

Nous avons été confrontés à quelques problèmes à ce stade, le plus no-table étant le temps de génération qui pour certaines séquences de test peutdevenir prohibitif. C’est l’une des raisons pour laquelle nous avons décidéde ne pas modéliser les aspects de bas niveau du protocole dans le même


modèle, ce qui l’aurait sans doute rendu inutilisable pour générer des tests.

Pour concrétiser et exécuter nos tests, nous avons choisi de transformer lessuites de tests générés avec CertifyIt en scripts python. Pour ce faire, nousavons utilisé l’export depuis CertifyIt vers XML, puis employé un petit scriptpour transformer ce fichier XML en modules et scripts python nécessaires àl’exécution des tests. On trouvera un extrait d’une des suites de tests ainsigénérées en Annexe A.1.

Une fois cette étape terminée, il faut encore compléter l’écriture del’adaptateur qui permettra au code généré de piloter un client ou un brokerexistant. Réaliser l’adaptateur se résume à établir un pont entre les diffé-rentes méthodes publiques du modèle et l’implémentation sous test.

Nous avons utilisé le client python du projet Paho, qui a demandé trèspeu d’efforts pour écrire l’adaptateur (voir Annexe A.2). En revanche, notresuite de tests qui emploie l’interface du broker n’est pas exécutable en l’état.

4.2.4 Verdict

Au vu de la difficulté de poser un verdict sur l’exécution d’un test (évo-quée ci-dessus section 3.3), la stratégie que nous avons retenue consiste àcomparer les trames virtuellement échangées au niveau du modèle avec cellesréellement échangées par le SUT.

Nous avons pour cela instrumenté le modèle afin de pouvoir extraire lesséquences de trames échangées à partir des cas de test, et stocké ces dernièresdans un fichier généré en même temps que le script de test.

D’autres problématiques sont alors apparues, comme le fait que les iden-tifiants de paquet ne peuvent être maitrisées depuis le modèle et requièrentun traitement particulier lors de la comparaison, ou la question de faire cor-respondre les entités du modèle avec celles des trames réellement échangées,etc.

Par ailleurs, nous avons relevé que l’implémentation du client a parfois uncomportement préventif et empêchera une action interdite que l’on chercheà tester, ce qui introduit des faux positifs dans les résultats de test.

Enfin, il s’est avéré que l’aspect asynchrone du système empêche de pré-dire le résultat attendu dans certains cas de tests qui deviennent non déter-ministes, puisque l’on ne peut contrôler l’enchainement exact des actions.

Pour toutes ces raisons, cette étape n’a encore pu être complètementautomatisée.

4.3 Proxy de test MQTTL’architecture logicielle du proxy MQTT évoqué au chapitre précédent

(section 3.2) est celle d’un serveur capable de maintenir des couples deconnexions entre les clients et le broker.


Figure 4.8 – Architecture du proxy de test MQTT

Comme on peut le voir Figure 4.8, le proxy est donc capable de restertransparent et se contenter d’analyser le trafic (client 1), mais peut aussimodifier à la volée voire supprimer les trames échangées dans les deux sens(client 2).

4.3.1 Réalisation

Nous avons écrit un petit proxy pour MQTT en python sur la base del’architecture proposée et mis son code à disposition sur GitHub 5.

Ce proxy consiste en un serveur TCP multi-threads. Il est configuréen lui donnant l’adresse du broker que l’on veut substituer, et va attendreles connexions des clients sur son adresse propre. Pour chaque client qui seconnecte, il ouvre une connexion client vers le broker, et transmettra ensuiteles trames MQTT de part et d’autre.

4.3.2 Modélisation du protocole

Si un simple proxy MQTT n’a nullement besoin de reconnaitre le proto-cole sous-jacent pour fonctionner, les fonctionnalités de validation et d’alté-ration des trames imposent de modéliser la structure des trames du protocolepour pouvoir les manipuler.

Nous avons donc réalisé une bibliothèque capable de décoder des tramesMQTT, éventuellement les modifier, et les restituer sous forme binaire (voirextraits du fichier mqtt_protocol.py en Annexe A.3).

La conception est orientée objet, toute trame MQTT étant représen-tée par un objet de type MQTTPacket qui comporte l’entête fixe et un ob-jet MQTTBody pour le reste du paquet. Différentes sous-classes héritent deMQTTBody et seront utilisées en fonction du type de paquet reçu.

5. https://github.com/yoch/MQTT-Proxy

https://github.com/yoch/MQTT-Proxy


Toutes ces classes comportent des méthodes _decode et _encode per-mettant respectivement de décoder une trame binaire reçue pour initialiserl’objet ou de créer une trame binaire depuis un objet. Ainsi chaque trameentrante est transformée en objet, et peut être reconvertie en trame binaireavant de la transmettre de l’autre coté.

D’autres méthodes ont ensuite été ajoutées aux objets afin de les enrichiren fonctionnalités, comme check qui permet de vérifier la validité d’unetrame à l’aide d’assertions et remonte en cas d’erreur un code permettantde connaitre exactement quelle portion de la norme est en cause.

4.3.3 Intégration au script de test

Notre proxy s’est avéré très utile pour s’intégrer au processus de test.En effet, il permet de :— valider la structure binaire des trames échangées, ce qui n’est pas pris

en charge par la modélisation fonctionnelle évoquée plus haut ;— récupérer simplement l’ensemble des trames échangées pour chaque

cas de test, dans le but de valider ou non ledit cas.L’architecture finale du processus de test est schématisée Figure 4.9.

On peut voir que même si le système est composé d’un broker et d’un client,il suffit d’initier des actions sur le client (qui sert d’interface) pour quel’ensemble des échanges soit récupéré par le proxy et analysé.

Figure 4.9 – Notre processus du test pour MQTT


4.4 BilanNous présentons ici les résultats de nos expérimentations avec le modèle

décrit ci-dessus.

4.4.1 Tests générés avec CertifyIt

Nous avons généré deux suites de tests avec CertifyIt, soit en tout unequarantaine de tests :TestAuth visant à tester les fonctionnalités d’authentification, avec 11 tests

générés ;TestPublish pour tester le fonctionnement du Publish/Subscribe tel que

défini par MQTT, avec 27 tests générés.On peut voir en Table 4.1 le nombre de scénarios du modèle atteints et

le nombre de scénarios que le générateur n’a pas pu atteindre pour chaquesuite de test 6.

Sont également indiqués le nombre d’exigences couvertes pour chaquesuite de test. Il convient ici de préciser que ce décompte n’est pas lié auxexigences définies par la norme MQTT, chaque exigence dont il est ques-tion ici décrit un comportement complet qui peut inclure un grand nombred’exigences normatives.

Table 4.1 – Statut de la génération des scénarios et couverture des tests

reached undetermined covered uncoveredTestAuth 36 3 5 16TestPublish 97 13 21 1

En sachant que tous les aspects fonctionnels du protocole n’ont pas en-core été modélisés, ces résultats nous semblent encourageants. Le principalsouci à ce stade reste le temps de génération et la difficulté d’atteindre cer-tains scénarios, sans doute de par la complexité du modèle.

4.4.2 Modélisation du format des trames

La modélisation du format binaire des trames MQTT a été réalisée ad-hoc en langage python, d’une part pour éviter de surcharger le modèle initial,et d’autre part afin d’en faire bénéficier notre proxy.

L’ensemble des commandes MQTT a été ainsi formalisé, ainsi que toutesles exigences définies par la norme à ce sujet. En revanche, nous n’avons

6. Nous ne relevons pas ici les scénarios marqués comme unreachable car ils sont laconséquence du choix des fixtures pour chaque suite de test. A noter également que nousavons limité la profondeur de recherche à 10 à cause de problèmes de mémoire et delenteur.


pas exploité ce modèle pour générer des cas de test, mais surtout pour lavalidation des trames transitant par notre proxy.

Un module permettant de faire du fuzzing en altérant les échanges MQTTa également été développé par dessus ce modèle, avec la possibilité de mo-difier les champs selon des critères établis (par ex. test aux limites), maisnous n’avons pas approfondi cette voie.

4.4.3 Exécution des test

Nous avons pu réaliser la couche d’adaptation pour le client en pythonsans difficulté notable, ce qui nous permet d’exécuter la seconde suite detests. Pour pouvoir exécuter la première suite de tests, il reste à écrire l’adap-tateur vers un broker de notre choix. De la même façon, tester une autreimplémentation de client nécessite l’écriture d’une couche d’adaptation spé-cifique.

Le proxy a également été intégré dans le processus de test avec succès,ce qui nous permet de valider le format des trames échangées entre le brokeret les clients, ainsi que d’obtenir la trace des échanges entre le broker et lesclients.

L’extraction des séquences de trames attendues à partir du modèle anécessité d’introduire certaines conventions dans le modèle et d’écrire unoutil spécifique permettant d’obtenir ces séquences depuis les cas de test.

Toutefois, la validation des tests exécutés pose quant à elle un défi bienplus important, et nous n’avons pas été en mesure d’automatiser le processuspour les raisons invoquées en section 4.2.4. C’est pourquoi, nos tests sontpour l’instant analysés et validés manuellement.

4.4.4 Validation

On trouvera en Annexe B la trace produite par les 27 cas de la suite detests TestPublish. Nous avons étudié attentivement l’ensemble des résul-tats :

— 9 cas de tests provoquent une exception du coté client. Parmi ces cas, 5d’entre eux correspondent à une protection ajoutée par l’implémenta-tion, et 4 d’entre eux proviennent d’un bug du client. Tous ces dernierscas sont liés à une mauvaise gestion de la taille maximale des sujets ;

— 2 cas de tests impliquant des sujets invalides (contenant un caractèrenull) provoquent une exception du proxy. Deux brokers différents ontété testés sur ce cas par la suite, tous deux présentant des défauts(dans les deux cas pour Mosquitto, dans un seul pour HiveMQ) ;

— Le problème de non déterminisme évoqué plus haut est bien visible,la plupart des séquences différant de celle attendues, que ce soit pourune raison d’ordre ou de trames supplémentaires ;


— Le client python Paho a comme particularité de se reconnecter au-tomatiquement en cas de déconnexion du broker, ce qui ajoute deséchanges de messages inattendus ;

— Les comportements testés sont variés, mais l’on ne peut prétendrequ’ils soient exhaustifs, et certains cas de tests ne sont pas bien diffé-renciés (semblent redondants ou peu pertinents).

— Le modèle semble cohérent, toutes les traces produites étant parfai-tement valides, même si notre introduction de l’asynchronisme peutdonner des traces plus courtes que dans la réalité.

Chapitre 5

Conclusion

Notre travail nous a permis d’étudier l’application du test dirigé par lesmodèles au domaine de la communication au sein de l’Internet des objets,et plus globalement aux problématiques liées au réseau.

Même si le protocole MQTT n’est pas nécessairement représentatif detoute la complexité de cette question, et malgré le fait que notre travailpuisse être encore complété et approfondi, nous avons pu tirer quelquesenseignements importants de notre expérimentation et des difficultés quenous avons rencontrées.

Tout d’abord, il faut remarquer que la nature même des applicationsdistribuées sur le réseau complexifie fortement la modélisation : il faut eneffet prendre en compte la multiplicité des composants qui font partie dusystème ou de son environnement, ainsi que de l’asynchronisme fréquent descommunications qui tend à rendre le modèle non-déterministe.

Mais cette complexité impacte aussi l’observation du système sous test,comme nous l’avons développé dans ce document. Le modèle doit permettred’analyser l’ensemble du système, y compris les composants qui ne sont passous le contrôle du testeur, de valider l’ensemble des échanges, et d’identifierles éventuels responsables d’un échec.

L’usage de CertifyIt pour cette expérience nous a fait prendre consciencede certaines limites de l’outil. Il est notamment incapable de produire oud’exploiter des diagrammes de séquence, et ne supporte pas bien les mo-dèles non-déterministes. La comparaison avec les solutions de modélisationexistant dans le monde des télécommunications nous parait particulièrementintéressante à cet égard [2].

Même en envisageant l’usage d’autres outils voire d’autres paradigmesde modélisation pour le test des systèmes connectés, nous pensons que laréflexion devra passer par l’anticipation des problèmes que nous avons ren-contré dans notre exploration de la question.

47

CHAPITRE 5. CONCLUSION 48

Notre contribution pourrait servir de base pour la validation des implé-mentations MQTT existantes. Peu d’outils existent encore à ce sujet, le seuldont nous ayons connaissance étant celui de Ian Craggs 1, également basé surle concept model-based testing [3] mais qui se distingue de notre approchepar son orientation ad-hoc.

Il est toutefois intéressant de noter que l’auteur s’est trouvé confronté àdes questions similaires, et que les réponses apportées vont souvent dans lemême sens que notre travail.

Pour notre recherche, nous nous sommes focalisés essentiellement sur lesquestions de conformité et d’interopérabilité des implémentations. La di-mension évolutive de notre modèle n’a pas été étudiée, mais n’en reste pasmoins intéressante à évaluer, les normes pouvant évoluer.

Les aspects de sécurité du protocole pourraient quant à eux faire l’objetd’une étude séparée, même si comme nous l’avons montré une grande partde cette problématique est déléguée aux applications et ne dépend pas duprotocole.

1. https://github.com/eclipse/paho.mqtt.testing

https://github.com/eclipse/paho.mqtt.testing

Bibliographie

[1] Andrew Banks et Rahul Gupta. MQTT Version 3.1.1. Rapp. tech.OASIS standard, 2014.

[2] Conformiq. Testing Bluetooth Protocol Stacks with Computer-GeneratedTests. Rapp. tech. url : https://www.conformiq.com/wp-content/uploads/2015/02/Bluetooth-Technology-Brief.pdf.

[3] Ian Craggs. More Rigorous Testing for MQTT Servers. Model-BasedTesting. 18 oct. 2014. url : http://modelbasedtesting.co.uk/?p=144 (visité le 29/06/2016).

[4] ETSI. « Methods for Testing and Specification (MTS) ; Model-BasedTesting (MBT) ; Requirements for Modeling Notations ». In : ETSIES (2011).

[5] Gartner Says 6.4 Billion Connected. url : http://www.gartner.com/newsroom/id/3165317 (visité le 07/01/2016).

[6] JoramMQ, a distributed MQTT broker for the Internet of Things.Sept. 2014. url : http://www.scalagent.com/IMG/pdf/JoramMQ_MQTT_white_paper-v1-2.pdf.

[7] Valerie Lampkin et al. Building Smarter Planet Solutions with MQTTand IBM WebSphere MQ Telemetry. en. IBM Redbooks, sept. 2012.isbn : 978-0-738-43708-8.

[8] Object Constraint Language, v2.4. Rapp. tech. www.omg.org, fév. 2014.url : http://www.omg.org/spec/OCL/2.4.

[9] Andy Piper. Eclipse Paho Progress Report. EclipseCon 2012, avr.2012. url : http://www.slideshare.net/andypiper/eclipse-paho-progress-report-eclipsecon-2012 (visité le 13/09/2016).

[10] Protocol Analysis. Juin 2014. url : http://www.onem2m.org/images/files/deliverables/TR- 0009- Protocol_Analysis- V0_7_0_1.pdf.

[11] Andy Stanford-Clark. « Integrating monitoring and telemetry de-vices as part of enterprise information resources ». In : WebSphere MQIntegrator (2002).

49

https://www.conformiq.com/wp-content/uploads/2015/02/Bluetooth-Technology-Brief.pdf

https://www.conformiq.com/wp-content/uploads/2015/02/Bluetooth-Technology-Brief.pdf

http://modelbasedtesting.co.uk/?p=144

http://modelbasedtesting.co.uk/?p=144

http://www.gartner.com/newsroom/id/3165317

http://www.gartner.com/newsroom/id/3165317

http://www.scalagent.com/IMG/pdf/JoramMQ_MQTT_white_paper-v1-2.pdf

http://www.scalagent.com/IMG/pdf/JoramMQ_MQTT_white_paper-v1-2.pdf

http://www.omg.org/spec/OCL/2.4

http://www.slideshare.net/andypiper/eclipse-paho-progress-report-eclipsecon-2012

http://www.slideshare.net/andypiper/eclipse-paho-progress-report-eclipsecon-2012

http://www.onem2m.org/images/files/deliverables/TR-0009-Protocol_Analysis-V0_7_0_1.pdf



BIBLIOGRAPHIE 50

[12] Sasu Tarkoma. Publish / Subscribe Systems : Design and Principles.Wiley, 18 juin 2012. isbn : 978-1-118-35429-2.

[13] The Internet of Things Protocol stack - from sensors to business value.url : https://entrepreneurshiptalk.wordpress.com/2014/01/29/the-internet-of-thing-protocol-stack-from-sensors-to-business-value/ (visité le 10/01/2016).

[14] Unified Modeling Language 2.5. Rapp. tech. www.omg.org, 2015. url :http://www.omg.org/spec/UML/2.5.

[15] Mark Utting, Alexander Pretschner et Bruno Legeard. « A taxo-nomy of model-based testing approaches ». In : Software Testing, Ve-rification and Reliability 22.5 (2012), p. 297–312.

[16] Lucy Zhang. Building Facebook Messenger. Août 2011. url : https://www.facebook.com/notes/facebook-engineering/building-facebook-messenger/10150259350998920/ (visité le 05/07/2016).

https://entrepreneurshiptalk.wordpress.com/2014/01/29/the-internet-of-thing-protocol-stack-from-sensors-to-business-value/



http://www.omg.org/spec/UML/2.5

https://www.facebook.com/notes/facebook-engineering/building-facebook-messenger/10150259350998920/



Remerciements

Je tiens à remercier toutes les personnes qui m’ont aidé tout au long dece travail de recherche.

Tout d’abord, j’adresse mes plus vifs remerciements à M. Fabrice Bou-quet qui a encadré mon travail pour ses conseils précieux lors de toutes lesdiscussions que nous avons eues, pour la qualité de ses explications, et pouravoir su me guider tout au long de ma recherche. Ce mémoire a bénéficié desa relecture et remarques avisées sur le fond comme sur la forme.

Je remercie M. Fabien Peureux qui m’a encouragé à suivre le cursus derecherche, et qui me fait l’honneur de faire partie de mon jury.

Je tiens également à exprimer ma gratitude envers l’entreprise Smartes-ting pour m’avoir accordé une licence d’utilisation de leur logiciel CertifyItdans le cadre de cette recherche.

Merci enfin à toute ma famille pour leur soutien, en particulier monépouse Ochrite qui m’a encouragé tout au long de mon Master, et sans quice mémoire n’aurait pas été possible.

51

Annexe A

Codes sources (extraits)

A.1 Suite de testsfrom mqtt import *from mqtt_enums import *

# publish (68-e3-eb)def test_16():

Client2.connection(BrokerInstance)Client2.connect(ClientIdentifier.CLIENTID_NORMAL_1, False, 36)Client2.subscribe(Utf8Type.UTF8_DATA_NORMAL_2, 0)Client2.publish(Utf8Type.UTF8_DATA_NORMAL_2,

PayloadType.BINARY_DATA_EMPTY, 0, False)↪→

# connect (68-fc-66)def test_17():

Client2.connection(BrokerInstance)Client1.connection(BrokerInstance)Client1.connect(ClientIdentifier.CLIENTID_EMPTY, True, 37)Client2.connect(ClientIdentifier.CLIENTID_EMPTY, True, 37)

# process_messages (68-2e-6d)def test_26():

Client1.connection(BrokerInstance)Client1.connect(ClientIdentifier.CLIENTID_NORMAL_1, True, 36)Client1.publish(Utf8Type.UTF8_DATA_NORMAL_2,

PayloadType.BINARY_DATA_TOO_LONG, 2, False)↪→

BrokerInstance.process_messages()Client1.process_messages()BrokerInstance.process_messages()

excepted = [[Client1.send_disconnect()],[Client2.send_connect(ClientIdentifier.CLIENTID_EMPTY, False, 5,

ClientName.NONE, ClientPassword.NONE),BrokerInstance.send_connack(Client2,ConnectReturnCode.IDENTIFIER_REJECTED)],

↪→

↪→

↪→

52

ANNEXE A. CODES SOURCES (EXTRAITS) 53

[Client2.send_connect(ClientIdentifier.CLIENTID_EMPTY, True, 36,ClientName.NONE, ClientPassword.NONE),BrokerInstance.send_connack(Client2, ConnectReturnCode.OK),Client2.send_disconnect()],

↪→

↪→

↪→

# ...[Client1.send_connect(ClientIdentifier.CLIENTID_EMPTY, True, 36,

ClientName.NONE, ClientPassword.NONE),BrokerInstance.send_connack(Client1, ConnectReturnCode.OK),Client1.send_subscribe(1, Utf8Type.UTF8_DATA_NORMAL_2, 2),BrokerInstance.send_suback(Client1, 1), Client1.send_publish(2,Utf8Type.UTF8_DATA_NORMAL_2, PayloadType.BINARY_DATA_TOO_LONG,1, False, False), BrokerInstance.send_publish(Client1,Utf8Type.UTF8_DATA_NORMAL_2, PayloadType.BINARY_DATA_TOO_LONG,2, False), Client1.send_pubrec(1),BrokerInstance.send_pubrel(Client1, 1),BrokerInstance.send_puback(Client1, 2),Client1.send_pubcomp(1)]

↪→

↪→

↪→

↪→

↪→

↪→

↪→

↪→

↪→

↪→

↪→

]


A.2 Adaptateur pour le client MQTTimport paho.mqtt.client as mqtt

class Client:def __init__(self):

self.client = mqtt.Client()

def __del__(self):self.disconnect()del self.client

def connect(self, server):#Hack: se contente de définir son adresseself.address = server.host, server.port

def disconnect(self):self.client.loop_stop()self.client.reinitialise()

def publish(self, topic, payload, qos, retain):self.client.publish(topic, payload, qos, retain)

def send_connect(self, client_id, clean, keepalive):host, port = self.address#Hack: force these valuesself.client._client_id = client_idself.client._clean_session = cleanself.client.connect(host, port, keepalive)self.client.loop_start()

def send_disconnect(self):self.client.disconnect()

def setup_id(self, nom, passw):#self.client.username_pw_set(nom, passw)if nom is not None:

nom = nom.encode('utf8')if passw is not None:

passw = passw.encode('utf8')self._username = nomself._password = passw

def subscribe(self, topic, qos):self.client.subscribe(topic, qos)

def unsubscribe(self, topic):self.client.unsubscribe(topic)


A.3 Modélisation binaire des tramesclass MQTTPacket:

def __init__(self, buf):self._data = bufself._decode(buf)

def _decode(self, buf):self.command = buf[0] >> 4self.flags = buf[0] & 0xfself.length = remaining_length_decode(buf)self._pos = next(i for i in range(1,5) if buf[i] & 128 == 0) + 1cls = MQTTCommandRegistry.get_cls(self.command)self.packet = cls(buf, self._pos)

def check(self):assert len(self._data) == self._pos + self.length, 'invalid length'self.packet.check()

def _encode(self):tmp = bytearray()self.packet._encode(tmp)buf = bytearray()buf.append(self.command << 4 | self.flags)remaining_length_encode(len(tmp), buf)buf.extend(tmp)return buf

# ...

class MQTTBody:def __init__(self, buf, pos):

self.flags = buf[0] & 0xfself._decode(buf, pos)

class MQTTConnect(MQTTBody):def _decode(self, buf, pos):

self.protocol, pos = get_utf8_string(buf, pos)self.protolevel, pos = get_uint8(buf, pos)cflags, pos = get_uint8(buf, pos)assert (cflags & 0x1) == 0, 'reserved flag'self.clean = (cflags & 0x2) >> 1self.wflag = (cflags & 0x4) >> 2self.wqos = (cflags & 0x18) >> 3self.wrflag = (cflags & 0x20) >> 5self.pflag = (cflags & 0x40) >> 6self.uflag = (cflags & 0x80) >> 7self.keepalive, pos = get_uint16(buf, pos)self.clientid, pos = get_utf8_string(buf, pos)

if self.wflag:self.will_topic, pos = get_utf8_string(buf, pos)self.will_msg, pos = get_binary_string(buf, pos)


else:self.will_topic = Noneself.will_msg = None

if self.uflag:self.username, pos = get_utf8_string(buf, pos)

else:self.username = None

if self.pflag:self.userpassword, pos = get_binary_string(buf, pos)

else:self.userpassword = None

def check(self):assert self.flags == 0, '[MQTT-3.1.2-3]'assert (self.protocol == 'MQTT' and self.protolevel == 4) or

(self.protocol == 'MQIsdp' and self.protolevel == 3), 'invalidor unkown protocol'

↪→

↪→

assert (self.wflag != 0 or self.wqos == 0), '[MQTT-3.1.2-13]'assert self.wqos != 3, '[MQTT-3.1.2-14]'assert (self.wflag != 0 or self.wrflag == 0), '[MQTT-3.1.2-15]'assert (self.uflag != 0 or self.pflag == 0), '[MQTT-3.1.2-22]'

def _encode(self, buf):set_utf8_string(self.protocol, buf)set_uint8(self.protolevel, buf)cflags = self.clean << 1 | self.wflag << 2 | self.wqos << 3 |

self.wrflag << 5 | self.pflag << 6 | self.uflag << 7↪→

set_uint8(cflags, buf)set_uint16(self.keepalive, buf)set_utf8_string(self.clientid, buf)if self.wflag:

set_utf8_string(self.will_topic or '', buf)set_binary_string(self.will_msg or '', buf)

if self.uflag:set_utf8_string(self.username or '', buf)

if self.pflag:set_binary_string(self.userpassword or '', buf)

def read_paquet(sock):buf = bytearray()read_fixed_header(sock, buf)length = remaining_length_decode(buf)# read the whole packetwhile len(buf) < length + 2:

data = sock.recv(length + 2 - len(buf))buf.extend(data)

packet = MQTTPacket(buf)# check the received packetpacket.check()# encode and return new packetreturn packet._encode()

Annexe B

Log des tests exécutés

TEST: connect (68-15-95)Exception occured in client side: Payload too large.------------------------------------------------------------TEST: connect (68-79-ca)excepted:

["<CONNECT: client_id='', username=None, password=None, clean=1, keepalive=36>",'<CONNACK: code=0>',"<CONNECT: client_id='aaa', username=None, password=None, clean=0, "'keepalive=5>']retrieved:

["<CONNECT: protocol='MQTT', level=4, clientid='', username=None, "'password=None, clean=1, keepalive=36>','<CONNACK: session_present=0, code=0>',"<CONNECT: protocol='MQTT', level=4, clientid='aaa', username=None, "'password=None, clean=0, keepalive=5>',"<CONNECT: protocol='MQTT', level=4, clientid='aaa', username=None, "'password=None, clean=0, keepalive=5>','<CONNACK: session_present=1, code=0>']

------------------------------------------------------------TEST: connect (68-9f-0a)excepted:

["<CONNECT: client_id='bbb', username=None, password=None, clean=1, "'keepalive=5>','<CONNACK: code=0>',"<CONNECT: client_id='bbb', username=None, password=None, clean=0, "'keepalive=5>','<CONNACK: code=0>']retrieved:

["<CONNECT: protocol='MQTT', level=4, clientid='bbb', username=None, "'password=None, clean=1, keepalive=5>','<CONNACK: session_present=0, code=0>',"<CONNECT: protocol='MQTT', level=4, clientid='bbb', username=None, "'password=None, clean=0, keepalive=5>','<CONNACK: session_present=1, code=0>','<PINGREQ: >']

------------------------------------------------------------TEST: connect (68-ca-0e)excepted:

57

ANNEXE B. LOG DES TESTS EXÉCUTÉS 58

["<CONNECT: client_id='', username=None, password=None, clean=0, keepalive=5>",'<CONNACK: code=2>']retrieved:

["<CONNECT: protocol='MQTT', level=4, clientid='', username=None, "'password=None, clean=0, keepalive=5>','<CONNACK: session_present=0, code=2>',"<CONNECT: protocol='MQTT', level=4, clientid='', username=None, "'password=None, clean=0, keepalive=5>','<CONNACK: session_present=0, code=2>',"<CONNECT: protocol='MQTT', level=4, clientid='', username=None, "'password=None, clean=0, keepalive=5>','<CONNACK: session_present=0, code=2>']

------------------------------------------------------------TEST: connect (68-d1-a6)excepted:

["<CONNECT: client_id='aaa', username=None, password=None, clean=0, "'keepalive=36>','<CONNACK: code=0>',"<SUBSCRIBE: packet_id=1, topic='bca', qos=2>",'<SUBACK: packet_id=1>',"<PUBLISH: packet_id=None, topic='bca', qos=0, retain=0, dup=0>","<PUBLISH: topic='bca', qos=2, retain=0>","<CONNECT: client_id='aaa', username=None, password=None, clean=0, "'keepalive=5>','<CONNACK: code=0>']retrieved:

["<CONNECT: protocol='MQTT', level=4, clientid='aaa', username=None, "'password=None, clean=0, keepalive=36>',"<SUBSCRIBE: packet_id=1 subscriptions=['bca':2]>","<PUBLISH: qos=0, retain=0, dup=0, topic='bca'>",'<CONNACK: session_present=1, code=0>','<SUBACK: packet_id=1, return_codes=[2]>',"<PUBLISH: qos=0, retain=0, dup=0, topic='bca'>","<CONNECT: protocol='MQTT', level=4, clientid='aaa', username=None, "'password=None, clean=0, keepalive=5>','<CONNACK: session_present=1, code=0>']

------------------------------------------------------------TEST: connect (68-d2-3f)excepted:

["<CONNECT: client_id='', username=None, password=None, clean=1, keepalive=36>",'<CONNACK: code=0>',"<CONNECT: client_id='bbb', username=None, password=None, clean=1, "'keepalive=5>']retrieved:

["<CONNECT: protocol='MQTT', level=4, clientid='', username=None, "'password=None, clean=1, keepalive=36>','<CONNACK: session_present=0, code=0>',"<CONNECT: protocol='MQTT', level=4, clientid='bbb', username=None, "'password=None, clean=1, keepalive=5>',"<CONNECT: protocol='MQTT', level=4, clientid='bbb', username=None, "'password=None, clean=1, keepalive=5>','<CONNACK: session_present=0, code=0>']

------------------------------------------------------------TEST: connect (68-fc-66)


excepted:["<CONNECT: client_id='', username=None, password=None, clean=1, keepalive=37>",'<CONNACK: code=0>',"<CONNECT: client_id='', username=None, password=None, clean=1, keepalive=37>",'<CONNACK: code=0>']retrieved:

["<CONNECT: protocol='MQTT', level=4, clientid='', username=None, "'password=None, clean=1, keepalive=37>','<CONNACK: session_present=0, code=0>',"<CONNECT: protocol='MQTT', level=4, clientid='', username=None, "'password=None, clean=1, keepalive=37>','<CONNACK: session_present=0, code=0>']

------------------------------------------------------------TEST: disconnect (68-83-fd)excepted:

["<CONNECT: client_id='aaa', username=None, password=None, clean=0, "'keepalive=36>','<CONNACK: code=0>','<DISCONNECT: >']retrieved:

["<CONNECT: protocol='MQTT', level=4, clientid='aaa', username=None, "'password=None, clean=0, keepalive=36>','<DISCONNECT: >','<CONNACK: session_present=0, code=0>']

------------------------------------------------------------TEST: disconnect (68-8e-49)excepted:

['<DISCONNECT: >']retrieved:

[]------------------------------------------------------------TEST: disconnect (68-8e-49)excepted:

['<DISCONNECT: >']retrieved:

[]------------------------------------------------------------TEST: disconnect (68-e8-24)excepted:

["<CONNECT: client_id='', username=None, password=None, clean=1, keepalive=36>",'<CONNACK: code=0>','<DISCONNECT: >']retrieved:

["<CONNECT: protocol='MQTT', level=4, clientid='', username=None, "'password=None, clean=1, keepalive=36>','<DISCONNECT: >','<CONNACK: session_present=0, code=0>']

------------------------------------------------------------TEST: publish (68-2c-98)Exception occured in client side: Invalid topic.------------------------------------------------------------TEST: publish (68-9a-6c)excepted:

["<CONNECT: client_id='', username=None, password=None, clean=1, keepalive=36>",


'<CONNACK: code=0>',"<SUBSCRIBE: packet_id=1, topic='abc', qos=2>",'<SUBACK: packet_id=1>',"<PUBLISH: packet_id=2, topic='abc', qos=2, retain=0, dup=0>","<PUBLISH: topic='abc', qos=2, retain=0>"]retrieved:

["<CONNECT: protocol='MQTT', level=4, clientid='', username=None, "'password=None, clean=1, keepalive=36>',"<SUBSCRIBE: packet_id=1 subscriptions=['abc':2]>","<PUBLISH: qos=2, retain=0, dup=0, topic='abc'>",'<CONNACK: session_present=0, code=0>','<SUBACK: packet_id=1, return_codes=[2]>','<PUBREC: packet_id=2>','<PUBREL: packet_id=2>','<PUBCOMP: packet_id=2>',"<PUBLISH: qos=2, retain=0, dup=0, topic='abc'>",'<PUBREC: packet_id=1>','<PUBREL: packet_id=1>','<PUBCOMP: packet_id=1>']

------------------------------------------------------------TEST: publish (68-e3-eb)excepted:

["<CONNECT: client_id='aaa', username=None, password=None, clean=0, "'keepalive=36>','<CONNACK: code=0>',"<SUBSCRIBE: packet_id=1, topic='bca', qos=0>",'<SUBACK: packet_id=1>',"<PUBLISH: packet_id=None, topic='bca', qos=0, retain=0, dup=0>","<PUBLISH: topic='bca', qos=0, retain=0>"]retrieved:

["<CONNECT: protocol='MQTT', level=4, clientid='aaa', username=None, "'password=None, clean=0, keepalive=36>',"<SUBSCRIBE: packet_id=1 subscriptions=['bca':0]>","<PUBLISH: qos=0, retain=0, dup=0, topic='bca'>",'<CONNACK: session_present=1, code=0>','<SUBACK: packet_id=1, return_codes=[0]>',"<PUBLISH: qos=0, retain=0, dup=0, topic='bca'>"]

------------------------------------------------------------TEST: subscribe (68-8c-59)Exception occured in client side: Invalid QoS level.------------------------------------------------------------TEST: subscribe (68-ce-5e)----------------------------------------Exception happened during processing of request from ('127.0.0.1', 58789)Traceback (most recent call last):

File "C:\Users\yoch\AppData\Local\Programs\Python\Python35-32\lib\socketserver.py", line 628, in process_request_threadself.finish_request(request, client_address)

File "C:\Users\yoch\AppData\Local\Programs\Python\Python35-32\lib\socketserver.py", line 684, in __init__self.handle()

File "C:/Users/yoch/IBM/rationalsdp/workspace/MQTT\mqtt_protocol.py", line 266, in _decodefilter, pos = get_utf8_string(buf, pos)

File "C:/Users/yoch/IBM/rationalsdp/workspace/MQTT\mqtt_protocol.py", line 420, in get_utf8_stringassert b'\x00' not in data, '[MQTT-1.5.3-2]'

AssertionError: [MQTT-1.5.3-2]


----------------------------------------excepted:

["<CONNECT: client_id='', username=None, password=None, clean=1, keepalive=36>",'<CONNACK: code=0>',"<SUBSCRIBE: packet_id=1, topic='ab\\x00', qos=0>"]retrieved:

["<CONNECT: protocol='MQTT', level=4, clientid='', username=None, "'password=None, clean=1, keepalive=36>',"<CONNECT: protocol='MQTT', level=4, clientid='', username=None, "'password=None, clean=1, keepalive=36>','<CONNACK: session_present=0, code=0>']

------------------------------------------------------------TEST: subscribe (68-f2-0f)excepted:

["<CONNECT: client_id='', username=None, password=None, clean=1, keepalive=36>",'<CONNACK: code=0>',"<SUBSCRIBE: packet_id=1, topic='bca', qos=0>",'<SUBACK: packet_id=1>',"<SUBSCRIBE: packet_id=2, topic='bca', qos=0>",'<SUBACK: packet_id=2>']retrieved:

["<CONNECT: protocol='MQTT', level=4, clientid='', username=None, "'password=None, clean=1, keepalive=36>',"<SUBSCRIBE: packet_id=1 subscriptions=['bca':0]>","<SUBSCRIBE: packet_id=2 subscriptions=['bca':0]>",'<CONNACK: session_present=0, code=0>','<SUBACK: packet_id=1, return_codes=[0]>','<SUBACK: packet_id=2, return_codes=[0]>']

------------------------------------------------------------TEST: subscribe (68-f2-23)excepted:

["<CONNECT: client_id='bbb', username=None, password=None, clean=1, "'keepalive=36>','<CONNACK: code=0>',"<SUBSCRIBE: packet_id=1, topic='bca', qos=0>",'<SUBACK: packet_id=1>',"<SUBSCRIBE: packet_id=2, topic='bca', qos=2>",'<SUBACK: packet_id=2>']retrieved:

["<CONNECT: protocol='MQTT', level=4, clientid='bbb', username=None, "'password=None, clean=1, keepalive=36>',"<SUBSCRIBE: packet_id=1 subscriptions=['bca':0]>","<SUBSCRIBE: packet_id=2 subscriptions=['bca':2]>",'<CONNACK: session_present=0, code=0>','<SUBACK: packet_id=1, return_codes=[0]>','<SUBACK: packet_id=2, return_codes=[2]>']

------------------------------------------------------------TEST: subscribe (68-f2-fd)excepted:

["<CONNECT: client_id='aaa', username=None, password=None, clean=1, "'keepalive=36>','<CONNACK: code=0>',"<SUBSCRIBE: packet_id=1, topic='abc', qos=0>",'<SUBACK: packet_id=1>',


"<SUBSCRIBE: packet_id=2, topic='abc', qos=1>",'<SUBACK: packet_id=2>']retrieved:

["<CONNECT: protocol='MQTT', level=4, clientid='aaa', username=None, "'password=None, clean=1, keepalive=36>',"<SUBSCRIBE: packet_id=1 subscriptions=['abc':0]>","<SUBSCRIBE: packet_id=2 subscriptions=['abc':1]>",'<CONNACK: session_present=0, code=0>','<SUBACK: packet_id=1, return_codes=[0]>','<SUBACK: packet_id=2, return_codes=[1]>']

------------------------------------------------------------TEST: unsubscribe (68-3c-bb)----------------------------------------Exception happened during processing of request from ('127.0.0.1', 58901)Traceback (most recent call last):

File "C:\Users\yoch\AppData\Local\Programs\Python\Python35-32\lib\socketserver.py", line 628, in process_request_threadself.finish_request(request, client_address)

File "C:\Users\yoch\AppData\Local\Programs\Python\Python35-32\lib\socketserver.py", line 684, in __init__self.handle()

File "C:/Users/yoch/IBM/rationalsdp/workspace/MQTT\mqtt_protocol.py", line 317, in _decodefilter, pos = get_utf8_string(buf, pos)

File "C:/Users/yoch/IBM/rationalsdp/workspace/MQTT\mqtt_protocol.py", line 420, in get_utf8_stringassert b'\x00' not in data, '[MQTT-1.5.3-2]'

AssertionError: [MQTT-1.5.3-2]----------------------------------------excepted:

["<CONNECT: client_id='aaa', username=None, password=None, clean=0, "'keepalive=36>','<CONNACK: code=0>',"<UNSUBSCRIBE: packet_id=1, topic='ab\\x00'>"]retrieved:

["<CONNECT: protocol='MQTT', level=4, clientid='aaa', username=None, "'password=None, clean=0, keepalive=36>',"<CONNECT: protocol='MQTT', level=4, clientid='aaa', username=None, "'password=None, clean=0, keepalive=36>','<CONNACK: session_present=0, code=0>']

------------------------------------------------------------TEST: unsubscribe (68-79-ae)excepted:

["<CONNECT: client_id='', username=None, password=None, clean=1, keepalive=36>",'<CONNACK: code=0>',"<SUBSCRIBE: packet_id=1, topic='bca', qos=1>",'<SUBACK: packet_id=1>',"<CONNECT: client_id='aaa', username=None, password=None, clean=1, "'keepalive=5>','<CONNACK: code=0>',"<UNSUBSCRIBE: packet_id=1, topic='bca'>",'<UNSUBACK: packet_id=1>']retrieved:

["<CONNECT: protocol='MQTT', level=4, clientid='', username=None, "'password=None, clean=1, keepalive=36>',"<SUBSCRIBE: packet_id=1 subscriptions=['bca':1]>",'<CONNACK: session_present=0, code=0>','<SUBACK: packet_id=1, return_codes=[1]>',


"<CONNECT: protocol='MQTT', level=4, clientid='aaa', username=None, "'password=None, clean=1, keepalive=5>',"<UNSUBSCRIBE: packet_id=1, unsubscriptions=['bca']>",'<CONNACK: session_present=0, code=0>','<UNSUBACK: packet_id=1>']

------------------------------------------------------------TEST: process_messages (68-2e-6d)Exception occured in client side: Payload too large.------------------------------------------------------------TEST: process_messages (68-41-02)Exception occured in client side: 'H' format requires 0 <= number <= 65535------------------------------------------------------------TEST: process_messages (68-7e-a3)Exception occured in client side: 'H' format requires 0 <= number <= 65535------------------------------------------------------------TEST: process_messages (68-97-a9)Exception occured in client side: 'H' format requires 0 <= number <= 65535------------------------------------------------------------TEST: process_messages (68-d9-db)Exception occured in client side: Payload too large.------------------------------------------------------------TEST: process_messages (68-ee-b3)Exception occured in client side: 'H' format requires 0 <= number <= 65535------------------------------------------------------------

Annexe C

Extraits de l’annexe B de lanorme MQTT

Table C.1 – Extraits des exigences normatives pour MQTT

MQTT-1.5.3-1 The character data in a UTF-8 encoded string MUST be well-formed UTF-8 as definedby the Unicode specification and restated in RFC 3629. If a Server or Client receives aControl Packet containing ill-formed UTF-8 it MUST close the Network Connection.

MQTT-1.5.3-2 A UTF-8 encoded string MUST NOT include an encoding of the null character U+0000.If a receiver (Server or Client) receives a Control Packet containing U+0000 it MUSTclose the Network Connection.

MQTT-2.2.2-1 Where a flag bit is marked as “Reserved” in Table 2.2 - Flag Bits, it is reserved for futureuse and MUST be set to the value listed in that table.

MQTT-2.2.2-2 If invalid flags are received, the receiver MUST close the Network Connection.MQTT-2.3.1-1 SUBSCRIBE, UNSUBSCRIBE, and PUBLISH (in cases where QoS > 0) Control Packets

MUST contain a non-zero 16-bit Packet Identifier.MQTT-2.3.1-3 If a Client re-sends a particular Control Packet, then it MUST use the same Packet

Identifier in subsequent re-sends of that packet. The Packet Identifier becomes availablefor reuse after the Client has processed the corresponding acknowledgement packet.

MQTT-2.3.1-5 A PUBLISH Packet MUST NOT contain a Packet Identifier if its QoS value is set to 0.MQTT-2.3.1-6 A PUBACK, PUBREC or PUBREL Packet MUST contain the same Packet Identifier as

the PUBLISH Packet that was originally sent.MQTT-2.3.1-7 Similarly to [MQTT-2.3.1-6], SUBACK and UNSUBACK MUST contain the Packet

Identifier that was used in the corresponding SUBSCRIBE and UNSUBSCRIBE Packetrespectively.

MQTT-3.1.0-1 After a Network Connection is established by a Client to a Server, the first Packet sentfrom the Client to the Server MUST be a CONNECT Packet.

MQTT-3.1.0-2 The Server MUST process a second CONNECT Packet sent from a Client as a protocolviolation and disconnect the Client.

MQTT-3.1.2-1 If the protocol name is incorrect the Server MAY disconnect the Client, or it MAY continueprocessing the CONNECT packet in accordance with some other specification.

64

ANNEXE C. EXTRAITS DE L’ANNEXE B DE LA NORME MQTT 65

MQTT-3.1.2-2 The Server MUST respond to the CONNECT Packet with a CONNACK return code 0x01(unacceptable protocol level) and then disconnect the Client if the Protocol Level is notsupported by the Server.

MQTT-3.1.2-4 If CleanSession is set to 0, the Server MUST resume communications with the Clientbased on state from the current Session (as identified by the Client identifier). If there isno Session associated with the Client identifier the Server MUST create a new Session. TheClient and Server MUST store the Session after the Client and Server are disconnected.

MQTT-3.1.2-5 After the disconnection of a Session that had CleanSession set to 0, the Server MUSTstore further QoS 1 and QoS 2 messages that match any subscriptions that the client hadat the time of disconnection as part of the Session state.

MQTT-3.1.2-6 If CleanSession is set to 1, the Client and Server MUST discard any previous Session andstart a new one. This Session lasts as long as the Network Connection.

MQTT-3.1.2-22 If the User Name Flag is set to 0, the Password Flag MUST be set to 0.MQTT-3.1.2-24 If the Keep Alive value is non-zero and the Server does not receive a Control Packet from

the Client within one and a half times the Keep Alive time period, it MUST disconnectthe Network Connection to the Client as if the network had failed.

MQTT-3.1.3-2 Each Client connecting to the Server has a unique ClientId. The ClientId MUST be usedby Clients and by Servers to identify state that they hold relating to this MQTT Sessionbetween the Client and the Server.

MQTT-3.1.3-5 The Server MUST allow ClientIds which are between 1 and 23 UTF-8 encoded bytes in length, and that contain only the characters"0123456789abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ".

MQTT-3.1.3-6 A Server MAY allow a Client to supply a ClientId that has a length of zero bytes. Howeverif it does so the Server MUST treat this as a special case and assign a unique ClientId tothat Client.

MQTT-3.1.3-7 If the Client supplies a zero-byte ClientId, the Client MUST also set CleanSession to 1.MQTT-3.1.3-9 If the Server rejects the ClientId it MUST respond to the CONNECT Packet with a

CONNACK return code 0x02 (Identifier rejected) and then close the Network Connection.MQTT-3.1.3-11 The User Name MUST be a UTF-8 encoded string as defined in Section 1.5.3.MQTT-3.1.4-1 The Server MUST validate that the CONNECT Packet conforms to section 3.1 and close

the Network Connection without sending a CONNACK if it does not conform.MQTT-3.1.4-2 If the ClientId represents a Client already connected to the Server then the Server MUST

disconnect the existing Client.MQTT-3.1.4-4 If CONNECT validation is successful the Server MUST acknowledge the CONNECT

Packet with a CONNACK Packet containing a zero return code.MQTT-3.2.0-1 The first packet sent from the Server to the Client MUST be a CONNACK Packet.MQTT-3.2.2-5 If a server sends a CONNACK packet containing a non-zero return code it MUST then

close the Network Connection.MQTT-3.3.1-1 The DUP flag MUST be set to 1 by the Client or Server when it attempts to re-deliver a

PUBLISH Packet.MQTT-3.3.1-4 A PUBLISH Packet MUST NOT have both QoS bits set to 1. If a Server or Client

receives a PUBLISH Packet which has both QoS bits set to 1 it MUST close the NetworkConnection.

MQTT-3.3.1-5 If the RETAIN flag is set to 1, in a PUBLISH Packet sent by a Client to a Server, theServer MUST store the Application Message and its QoS, so that it can be delivered tofuture subscribers whose subscriptions match its topic name.


MQTT-3.3.1-6 When a new subscription is established, the last retained message, if any, on each matchingtopic name MUST be sent to the subscriber.

MQTT-3.3.1-8 When sending a PUBLISH Packet to a Client the Server MUST set the RETAIN flag to1 if a message is sent as a result of a new subscription being made by a Client.

MQTT-3.3.1-9 It MUST set the RETAIN flag to 0 when a PUBLISH Packet is sent to a Client becauseit matches an established subscription regardless of how the flag was set in the messageit received.

MQTT-3.3.1-10 A PUBLISH Packet with a RETAIN flag set to 1 and a payload containing zero bytes willbe processed as normal by the Server and sent to Clients with a subscription matching thetopic name. Additionally any existing retained message with the same topic name MUSTbe removed and any future subscribers for the topic will not receive a retained message.

MQTT-3.3.2-1 The Topic Name MUST be present as the first field in the PUBLISH Packet Variableheader. It MUST be a UTF-8 encoded string.

MQTT-3.3.2-2 The Topic Name in the PUBLISH Packet MUST NOT contain wildcard characters.MQTT-3.8.3-1 The Topic Filters in a SUBSCRIBE packet payload MUST be UTF-8 encoded strings as

defined in Section 1.5.3.MQTT-3.8.3-3 The payload of a SUBSCRIBE packet MUST contain at least one Topic Filter / QoS pair.

A SUBSCRIBE packet with no payload is a protocol violation.MQTT-3.8.4-1 When the Server receives a SUBSCRIBE Packet from a Client, the Server MUST respond

with a SUBACK Packet.MQTT-3.8.4-2 The SUBACK Packet MUST have the same Packet Identifier as the SUBSCRIBE Packet

that it is acknowledging.MQTT-3.8.4-3 If a Server receives a SUBSCRIBE Packet containing a Topic Filter that is identical to

an existing Subscription’s Topic Filter then it MUST completely replace that existingSubscription with a new Subscription.

MQTT-3.8.4-5 The SUBACK Packet sent by the Server to the Client MUST contain a return code foreach Topic Filter/QoS pair. This return code MUST either show the maximum QoS thatwas granted for that Subscription or indicate that the subscription failed.

MQTT-3.9.3-1 The order of return codes in the SUBACK Packet MUST match the order of Topic Filtersin the SUBSCRIBE Packet.

MQTT-3.9.3-2 SUBACK return codes other than 0x00, 0x01, 0x02 and 0x80 are reserved and MUSTNOT be used.

MQTT-3.10.3-1 The Topic Filters in an UNSUBSCRIBE packet MUST be UTF-8 encoded strings asdefined in Section 1.5.3, packed contiguously.

MQTT-3.10.3-2 The Payload of an UNSUBSCRIBE packet MUST contain at least one Topic Filter. AnUNSUBSCRIBE packet with no payload is a protocol violation.

MQTT-3.10.4-4 The Server MUST respond to an UNSUBSUBCRIBE request by sending an UNSUBACKpacket. The UNSUBACK Packet MUST have the same Packet Identifier as the UNSUB-SCRIBE Packet.

MQTT-3.10.4-5 Even where no Topic Subscriptions are deleted, the Server MUST respond with anUNSUBACK.

MQTT-3.12.4-1 The Server MUST send a PINGRESP Packet in response to a PINGREQ packet.MQTT-3.14.4-1 After sending a DISCONNECT Packet the Client MUST close the Network Connection.MQTT-3.14.4-2 After sending a DISCONNECT Packet the Client MUST NOT send any more Control

Packets on that Network Connection.MQTT-4.3.1-1 In the QoS 0 delivery protocol, the Sender MUST send a PUBLISH packet with QoS=0,

DUP=0.


MQTT-4.3.2-1 In the QoS 1 delivery protocol, the Sender MUST assign an unused Packet Identifiereach time it has a new Application Message to publish. MUST send a PUBLISH Packetcontaining this Packet Identifier with QoS=1, DUP=0. MUST treat the PUBLISH Packetas "unacknowledged" until it has received the corresponding PUBACK packet from thereceiver.

MQTT-4.3.2-2 In the QoS 1 delivery protocol, the Receiver MUST respond with a PUBACK Packetcontaining the Packet Identifier from the incoming PUBLISH Packet, having acceptedownership of the Application Message. After it has sent a PUBACK Packet the ReceiverMUST treat any incoming PUBLISH packet that contains the same Packet Identifier asbeing a new publication, irrespective of the setting of its DUP flag.

MQTT-4.3.3-1 In the QoS 2 delivery protocol, the Sender MUST assign an unused Packet Identifier whenit has a new Application Message to publish. MUST send a PUBLISH packet containingthis Packet Identifier with QoS=2, DUP=0. MUST treat the PUBLISH packet as "una-cknowledged" until it has received the corresponding PUBREC packet from the receiver.MUST send a PUBREL packet when it receives a PUBREC packet from the receiver.This PUBREL packet MUST contain the same Packet Identifier as the original PUBLISHpacket. MUST treat the PUBREL packet as "unacknowledged" until it has received thecorresponding PUBCOMP packet from the receiver. MUST NOT re-send the PUBLISHonce it has sent the corresponding PUBREL packet.

MQTT-4.3.3-2 In the QoS 2 delivery protocol, the Receiver MUST respond with a PUBREC containingthe Packet Identifier from the incoming PUBLISH Packet, having accepted ownershipof the Application Message. Until it has received the corresponding PUBREL packet,the Receiver MUST acknowledge any subsequent PUBLISH packet with the same PacketIdentifier by sending a PUBREC. It MUST NOT cause duplicate messages to be deliveredto any onward recipients in this case. MUST respond to a PUBREL packet by sendinga PUBCOMP packet containing the same Packet Identifier as the PUBREL. After ithas sent a PUBCOMP, the receiver MUST treat any subsequent PUBLISH packet thatcontains that Packet Identifier as being a new publication.

MQTT-4.4.0-1 When a Client reconnects with CleanSession set to 0, both the Client and Server MUSTre-send any unacknowledged PUBLISH Packets (where QoS > 0) and PUBREL Packetsusing their original Packet Identifiers.

MQTT-4.7.1-1 The wildcard characters can be used in Topic Filters, but MUST NOT be used within aTopic Name.

MQTT-4.7.1-2 The multi-level wildcard character MUST be specified either on its own or following atopic level separator. In either case it MUST be the last character specified in the TopicFilter.

MQTT-4.7.1-3 The single-level wildcard can be used at any level in the Topic Filter, including first andlast levels. Where it is used it MUST occupy an entire level of the filter.

MQTT-4.7.2-1 The Server MUST NOT match Topic Filters starting with a wildcard character (# or +)with Topic Names beginning with a $ character.

MQTT-4.7.3-1 All Topic Names and Topic Filters MUST be at least one character long.MQTT-4.7.3-2 Topic Names and Topic Filters MUST NOT include the null character (Unicode U+0000).MQTT-4.7.3-3 Topic Names and Topic Filters are UTF-8 encoded strings, they MUST NOT encode to

more than 65535 bytes.MQTT-4.8.0-1 Unless stated otherwise, if either the Server or Client encounters a protocol violation,

it MUST close the Network Connection on which it received that Control Packet whichcaused the protocol violation.

Résumé

Les objets connectés prennent une place de plus en plus importante dansnotre vie quotidienne, et cela s’accompagne de nombreux problèmes de qua-lité, de sécurité ou encore d’interopérabilité. Valider tous ces aspects avantla mise d’un produit sur le marché est donc indispensable pour l’industrie,or le test est souvent coûteux à mettre en œuvre.

Nous avons exploré l’approche du test dirigé par les modèles appliqué auxsystèmes d’objets connectés en réalisant un test de conformité basé sur desmodèles pour les implémentations du protocole MQTT. Un modèle abstraitdu protocole a été créé à l’aide des langages UML et OCL, et complété parla modélisation en python du format binaire défini par MQTT.

Nous avons pu générer deux suites de test avec le logiciel CertifyIt deSmartesting, l’une d’entre elles a été exécutée et analysée, nous permettantde trouver des bugs au sein de l’implémentation sous test.

Nos résultats indiquent que la nature asynchrone des communications,et plus généralement tous les aspects non déterministes du protocole étudié,posent des problèmes tant au niveau de la génération des tests que pourautomatiser leur validation, laissant la place à une étude plus approfondiede ce sujet.Mots-clés : Internet des Objets, MQTT, Test, Modèle

Abstract

Connected devices are playing an increasingly important role in our dailylives, and come with many problems of quality, security and interoperability.Validate these aspects before to bring products to market is essential for theindustry, but the product testing is often expensive.

We explored a model-driven testing approach by performing a modelbased testing of MQTT implementations. An abstract model of the protocolwas created using UML and OCL languages, and completed by modeling thebinary format defined by MQTT in python language.

We were able to generate two test suites with Smartesting CertifyIt soft-ware, one of them was executed and analyzed, enabling us to find some bugsin the implementation under test.

Our results indicate that the asynchronous nature of communications,and more generally non-deterministic aspects of MQTT are difficult to handleboth in the tests generation and for automating validation, leaving room forfurther study on this topic.Keywords : IoT, MQTT, Model Based Testing