Cours “Programmer l'Internet des objets” proposé sur la plateforme FUN-MOOC par l'Institut Mines Télécom.

Transcription de la vidéo de présentation des protocoles de l'Internet.

Vous connaissez sûrement le principe d'empilement protocolaire dans les réseaux. Chaque protocole fournit un service et se base sur celui de la couche inférieure pour le réaliser. Le modèle standard proposé par ISO définit 7 couches pour transporter les données d'une application n'importe où dans le monde. Dans la pratique, l'Internet a simplifié cette architecture, c'est pourquoi on retrouve moins de couche et que leur numéros ne sont pas contigus.

Les 2 premières couches en partant du bas permettent de transmettre les données binaires sur un support physique ou des ondes radio. Plusieurs organismes standardisent des protocoles pour ce niveau. Parmi les plus connus on peut citer l'IEE pour Ethernet, WiFi et Bluetooth. On peut également cité le 3GPP qui standardise les protocoles dédiés à la téléphonie mobile.

Chacun de ces protocoles et conçu pour fonctionner dans un environnement particulier.

Au dessus on retrouve le protocole IP standardisé par l'IETF. Il permet de construire un réseau mondial uniforme en masquant les spécificités des protocoles de niveau 2. IP définit ses règles d'adressage et de routage : c'est à dire comment trouver un chemin dans le réseau pour qu'en recopiant l'information de nœud en nœud on atteigne la destination.

Les experts de l'Internet aiment cette représentation en sablier où IP appairait en position centrale mais est plus petit comparé aux autres protocoles.

Par conception IP est très simple : à la fois pour être porté facilement sur de nombreux équipements de niveau 2 et être facilement utilisable par les couches hautes mais également pour traiter les données très rapidement dans les nœuds intermédiaires.

Au dessus on trouve 2 protocoles (TCP et UDP) qui ne sont mis en œuvre que dans les équipement d'extrémités :

• L'adresse IP permet de trouver une machine sur le réseau ;
• Les protocoles de niveau 4 permettent de d'identifier une application tournant sur la machine (assurant le multiplexage du canal de communication).

TCP est complexe et demande beaucoup de mémoire. Il permet entre autre de contrôler la communication, de retransmettre les données perdues, de déterminer le débit de transmission optimal.

UDP est un protocole minimal qui se contente d’aiguiller les données vers la bonne application sans contrôle du flux.

Au dessus on retrouve les applications qui selon le modèle ISO se trouvent dans la couche 7. Les applications sont très nombreuses, la plus largement répandue est HTTP qui sert à transporter les pages web et permet également des communications directes entres systèmes autonomes via les API REST)

Au niveau 3, on a à présent deux versions du protocole IP. La version 4 est la version historiquement déployée et elle a eu tellement de succès qu'il est de plus en plus difficile d'obtenir des adresses IPv4 pour les machines.

Pour permettre au réseau de continuer de fonctionner, une nouvelle version a été développée : IPv6 rend l'adressage quasi infini avec des adresses codées sur 128 bits.

IPv6 gagne peu à peu du terrain dans les usages classiques mais c'est surtout une brique essentielle pour l'IoT.

Les protocoles réseaux sont empilés les uns sur les autres, ceux du dessus utilisent les services offerts par ceux d’en dessous pour acheminer la donnée. Cela a donné lieu au modèle de référence de l’ISO qui structure les réseaux depuis les années 1970. En théorie, il y a 7 couches, mais l'internet a fait évoluer ce modèle et les numéros des couches, associés à des fonctionnalités, sont restés ; ce qui peut conduire à une numérotation étrange.

La couche 1 s’occupe de la modulation du signal binaire sur un support physique particulier (fibre optique, paire de cuivre, onde radio).

La couche 2 regroupe les mécanismes qui permettent de structurer cette donnée sous forme de bloc de taille finie appelées trames, de définir les méthodes d’accès, c’est-à-dire quand l’équipement peut émettre, et les formats des adresses utilisées pour identifier les équipements. Ethernet ou Wi-Fi sont des exemples de protocoles de niveau 2 (qui intègrent leur niveau 1).

Ces deux couches basses sont regroupées sous le nom d'Interface sur le schéma. Elles sont normalisées par différents organismes comme :

• l’IEEE (Institute of Electrical and Electronics Engineers) qui propose des standards comme Ethernet pour les réseaux filaires ou Bluetooth et Wifi pour les réseaux radio ;
• le 3GPP (3rd Generation Partnership Project) qui opère au même niveau et définit les protocoles pour la téléphonie cellulaire (4G) ;
• …

Les concepteurs de l’internet insistent sur le fait que le protocole en couche 3 qui joue ce rôle central, IP ¹⁾, a une interaction limitée avec aussi bien les couches basses qu’avec les protocoles de niveau supérieur ; d'où la représentation en sablier de l'image ci-dessous.

Le protocole IP s’adapte simplement à tout moyen de communication. IP propose ainsi une abstraction des moyens de communication aux couches applicatives, rendant l’accès au réseau et l’adressage universels. Le traitement dans les routeurs (équipements chargés d’aiguiller l’information dans le réseau) doit être le plus rapide possible pour traiter un maximum de paquets par seconde. De plus, IP ne spécialise pas le réseau pour un service ou un autre ; il ne fait qu’aiguiller les paquets vers la bonne destination. Le réseau Internet est un réseau mondial construit autour de ce protocole permettant potentiellement d'atteindre tous les équipements qui y sont connectés.

Si le niveau 3 permet de joindre une machine, le niveau 4 va permettre d’identifier l'application qui doit traiter les données. Les “adresses” de ces applications sont des numéros compris entre 1 et 65535 appelés ports. Par exemple, les serveurs Web utilisent le port numéro 80 ou le numéro 443. Le protocole TCP va surveiller les données transférées et sera capable de retransmettre des données perdues, ralentir ou accélérer le transfert de données s’il détecte une saturation du réseau. En revanche, sa mise en œuvre est complexe et coûteuse en mémoire. Dans les cas simple, UDP est préféré ; il n'apporte pas de traitement supplémentaire et se contente d'identifier les applications.

Dans le modèle architectural de l'internet, les applications (couche 7) utilisent directement les services de la couche 4, d'où le saut dans la numérotation.

Pour le grand public, l’internet désigne surtout la totalité de cet assemblage protocolaire et est souvent confondu avec l’application qui a démocratisé son usage : le Web. C'est vrai également pour les techniciens, le trafic produit par le Web est largement majoritaire dans l'Internet.

La figure suivante résume cet empilement protocolaire, ou pile protocolaire, majoritaire dans l'internet actuel.

Il existe deux versions du protocole IP. La version 4 ou IPv4 est la version historique largement déployée. Pour faire face à la pénurie d'adresse IPv4 sur 32 bits, l'IETF a développé une nouvelle version du protocole IPv6 qui reprend les principes qui ont fait le succès de l'internet, mais en étendant son adressage à 128 bits. Cette version, si elle est encore peu déployée dans l'internet des contenus, va être à la base de l'internet des objets qui demande un très grand nombre d'adresses.

Le Web utilise majoritairement le protocole HTTP. Et comme HTTP repose sur TCP, ces deux protocoles sont dominants sur le réseau. Les données transportées respectent également des formats spécifiques qui sont représentés en rose sur la figure.

Sur le graphique, au dessus de la couche 7, on représente comment les données transportées sont structurées avec des formats comme XML ou JSON.

Transcription de la vidéo Pourquoi le Web n'est pas ce que l'on croit (principes de REST) ⚙️ MOOC PLIDO

On s’intéresse aux principes derrière le Web et plus précisément les règles REST²⁾ qui permettent de produire des services robustes et fiables.

L'élément de base est la ressource que l'on peut définir comme un bloc de données de taille finie. Les ressources peuvent elles-même contenir des références à d'autres ressources, qui à leur tour vont faire références à d'autres ressources etc. Cela forme un maillage entre ressources que l'on compare à une toile d'areignée : web en anglais.

La ressource peut être par exemple une image. Dans ce cas elle ne fera pas référence à autre chose. Pour faire référence à une autre ressource son contenu doit être structuré et doit donc être définit dans un format où l'on peut facilement comprendre qu'une partie du contenu est une référence à un autre ressource.

HTML est un de ces langages qui permet aux pages web de se référencer entre elles par le biais de liens.

Pour référencer une ressource, elle doit pouvoir être identifier. Comme il s'agit d'un système mondial, chaque identifiant doit être unique dans le monde. Mais comment être sûr qu'un identifiant va être unique et que quelqu'un d'autre sur Terre ne va pas prendre le même ?

Avoir un endroit qui fournirait des identifiants uniques pour l'ensemble des ressources ne tiendrait pas la charge : on va donc prendre une approche hiérarchique.

On va construire un identifiant unique en ajoutant du texte à quelque chose que l'on sait unique. Je peux par exemple appeler localement une ressource “Image” : il y a eu de chance que je sois le seul au monde à l'avoir fait. Par contre si je préfixe la ressource avec mon numéro de téléphone ou mon numéro de sécurité sociale que le sait unique alors j'aurai un identifiant unique. Comme pour le numéro de téléphone, je peux choisir d'ajouter un nom de domaine qui m'appartient et qui est unique. Ca nous donne une idée de ma méthode utilisée pour construire ces identifiants uniques.

1. D'abord on déclare un schéma. Le schéma va indiquer quel élément unique j'utilise et éviter des confusions (par exemple entre un numéro de sécurité sociale et un numéro de téléphone). Le schéma définit également comment la suite sera structurée ;
2. Ensuite l'autorité (si le schéma l'impose) et qui est la partie unique ;
3. Après l'autorité, (c'est à dire la partie unique que je possède), je peux ajouter un chemin qui va identifier la ressource.

Ces 3 parties forment un URI ³⁾ qui définit un schéma d'adressage universel permettant d'allouer facilement des identifiant aux ressources tout en garantissant leur unicité.

Pour illustrer les usages :

• Spotify a définit son propre schéma. Il n'a ensuite plus besoin d'autorité mais structure le chemin afin de référencer une playlist.
• Tous les livres ont un numéro unique ISBN les identifiants, il peut être intégré dans un URI.

Précisons que ces deux types d'identifiants permettent de référencer un objet unique mais rien qu'en le lisant, on ne peut pas accéder à la ressource. Cette sous-famille des URI est désignée URN pour Universal Ressource Name.

Si en revanche en lisant la ressource on peut la localiser, on a une URL pour Universal Ressource Locator. Il faut bien voir que le but initial est de produire un identifiant unique. Le schéma https définit la manière dont sera construit la suite et dans un second temps uniquement, sera vu comme le protocole à utiliser pour accéder à la ressource. L'autorité est unique et dans un second temps, servira à localiser le serveur. Finalement le chemin va indiquer comment accéder à la ressource sur le serveur.

Donc les ressources de notre toile d'araignée mondiale sont présentes sur des serveurs et chaque ressource possède un identifiant unique. Dans un premier temps le client connait l'URI d'une ressource.

Si c'est une URL, il peut consulter le serveur, le serveur lui retourne la ressource, le client l'analyse et découvre les URI qu'elle contient. Il peut donc interroger le ou les autres serveurs pour reconstruire localement une partie de la toile nécessaire au traitement que le client veux effectuer.

On peut voir que les interactions client-serveur sont simples. Le client va gérer les interactions avec les ressources sur un serveur :

• Il peut par exemple récupérer une ressource grâce à une méthode GET ;
• Il peut également écrire les données dans une ressource existante grâce à un méthode PUT.

On verra que le nombre d'interaction est très limité. HTTP(S) est un moyen de mettre en œuvre ces méthodes.

Pour résumer, qu'est ce que REST ?

• On a des ressources qui sont des blocs d'information ;
• Ces ressources sont désignées par des identifiants uniques les URI ;
• Les ressources peuvent référencer d'autres ressources en contenant des URI ;
• Les serveurs hébergent les ressources et les clients interagissent avec les serveur via un ensemble réduit de primitives (commandes ou méthodes) ;
• Les serveurs ne font que répondre aux demandes des clients. Si un état est necessaire pour un service plus complexe, il est maintenu sur le client et pas sur le serveur.

L'architecture qui a conduit au Web est une formidable source d’inspiration pour le développement de nouveaux services car il est l’un des plus grands succès reposant sur le réseau Internet. Le Web forme de grands systèmes distribués et repose sur plusieurs principes qui le rendent universel et évolutif. La navigation avec un navigateur n’est que la partie visible du trafic ; les principes du web sont également utilisés pour le streaming vidéo, les échanges entre ordinateurs.

L’internet des objets est l’adaptation de cette architecture aux dispositifs contraints.

Le Web et ses extensions sont basés sur un modèle client-serveur. Les serveurs possèdent des ressources et les clients peuvent y accéder ou les modifier grâce à un protocole tel que HTTP. Le modèle client-serveur est quelque chose de courant dans les réseaux informatiques, mais le Web suit certaines directives de conception connues sous le nom de REST (REpresentational State Transfer).

Selon Roy Fielding, qui a défini ce modèle, REST est un ensemble de principes, de propriétés et de contraintes. REST utilise le modèle de communication client-serveur et utilise généralement le protocole HTTP (Hypertext Transfer Protocol).

Voici les 6 propriétés qui définissent REST :

• Architecture client-serveur : les serveurs sont les entités qui fournissent des services tels que l’heure, le partage de données, etc. ; les clients sont les entités qui interrogent ces services.
• Sans état (ou stateless) : cela signifie que l’état de l’interaction entre le client et le serveur n’est pas stocké. Chaque requête client est traitée comme une nouvelle demande indépendante. De cette façon, le serveur n’a pas besoin de stocker, suivre ou analyser les requêtes précédentes du même client.
• cacheability : les périphériques intermédiaires ainsi que les clients peuvent mettre en cache les réponses pour une utilisation ultérieure. Cela conduit à améliorer les performances.
• système en couches : cela signifie que les services peuvent être réalisés en utilisant des couches telles que différents serveurs responsables de différentes parties de services (stockage, recherche, etc.), mais le client ne sait pas s’il est connecté au serveur final ou intermédiaire.
• code à la demande (facultatif) : les serveurs peuvent éventuellement envoyer du code exécutable aux clients.
• interface uniforme : elle fait référence aux principes selon lesquelles une ressource doit avoir une seule représentation telle que les URI (Uniform Resource Identifier), et suivre certaines directives pour la dénomination, le format de lien et de données, etc. Il doit avoir suffisamment d’informations sur le traitement. Les ressources initiales telles que la page d’accueil d’un site Web, devraient avoir d’autres liens leur permettant de découvrir d’autres ressources.

Le respect de ces règles permet l’évolutivité du système en ajoutant continuellement des acteurs et de nouvelles données. L’objectif principal est de simplifier le comportement du serveur afin de servir le plus grand nombre de requêtes possible.

Dans les sections suivantes, nous revenons sur certaines des propriétés qui seront utiles pour comprendre son utilisation par l’internet des objets.

1-Qu'est ce qui est unique dans le monde ?

☐ un prénom
☐ un nom de famille
☑ un numéro de sécurité sociale utilisé en France
☑ un numéro de passeport
☑ un numéro de téléphone portable avec son préfixe international
☑ un numéro complet de compte en banque (IBAN)
☐ l'adresse IP de ma machine dans mon réseau privé
☑ l'adresse IP d'un serveur fun-mooc
☑ le nom de domaine plido.net
☐ le nom d'une ville 

2-Est-ce que le serveur garde un état des précédentes requêtes ?

☐ Oui
☑ Non 

3-Le World Wide Web est basé sur ce principe pour :

☑ pouvoir servir un grand nombre de requêtes, pouvoir servir un grand nombre de requêtes, - correct
☐ fonctionner à la fois sur des ordinateurs et des téléphones portables,
☐ chiffrer les communications.

Chaque ressource du Web est identifiée par une valeur unique appelée URI (Uniform Resource Identifier). Si l’URI contient des caractères internationaux, (comme les lettres accentuées, …) il est appelé IRI (International Resource Identifier).

Les URI permettent de désigner une ressource de manière non ambigüe, c'est-à-dire que l'on ne retrouvera pas le même URI pour désigner deux ressources différentes. Par construction, la structure de l’URI est hiérarchique, ce qui permet de créer des identificateurs uniques de manière distribuée. Si vous voulez identifier une ressource, vous devez posséder une séquence unique : un numéro de téléphone, un numéro de sécurité sociale, un nom de domaine. En y ajoutant quelque chose d'unique pour nous, cela crée un identifiant globalement unique.

Par exemple, on a une image que l'on veut identifier, on peut l'appeler

"image"

mais il y a peu de chance que ce nom soit unique, d'autres personnes sur Terre ont sûrement eu la même idée que nous. En revanche, si je la fais précéder de mon numéro de téléphone, on aura :

33667789078image

qui sera unique si je ne nomme qu'une seule ressource “image”. Un autre utilisateur sur le même principe pourra nommer sa ressource :

33667239018image

sans ambiguïté possible. Cependant, comme le numéro de téléphone est unique dans l'espace des numéros de téléphone, d'autres numéros uniques pourraient entrer en conflit dans d'autres espaces de numérotation.

Pour éviter les conflits, il est intéressant de donner, au début l'espace de numérotation, par exemple :

tel:33667789078image

et

ss:33667789078image

On aura donc deux identifiants uniques, même si le hasard a fait que ce numéro de téléphone et ce numéro de sécurité sociale coïncident.

Les URI formalisent ce principe. Le [RFC 3986] explique comment ils peuvent être construits.

Un URI commence par un schéma indiquant l’autorité de nommage, suivi d’une valeur d’autorité puis d’un chemin dans l’espace d’autorité. Des caractères comme les “:” ou les “/” sont utilisés pour améliorer la lisibilité de l'URI.

Par exemple :

• mailto:mduerst@ifi.unizh.ch
• ssh://utilisateur@example.com
• ftp://ftp.is.co.za/rfc/rfc1808.txt

Ainsi, si je mets une ressource sur mon site Web, celui-ci est identifié par un nom de domaine, par exemple example.com. Je suis propriétaire de ce nom. Je peux donc l’utiliser pour identifier de manière unique ma ressource. Si on reprend le principe de construction d’un URI, j’aurai :

• http://example.com/ma_ressource

Personne d’autre dans l’univers ne pourra identifier ses ressources avec cette chaîne de caractères puisque example.com m’appartient. Je dispose donc d’un espace de nommage infini sous example.com qui me permet de désigner l’ensemble infini de ressources sans que personne d’autre ne puisse prendre les mêmes noms. Un URI est une construction administrative permettant d’attribuer un identifiant unique global à une ressource spécifique.

L’URI a pour but de facilement nommer une ressource, de pouvoir lier les ressources entre elles pour former cette toile d’araignée mondiale. Le schéma définit à la fois l'espace de nommage de l'autorité et son format. Une adresse IP ou un nom de domaine comme autorité est à la fois un moyen d'assurer l'unicité globale, mais également de savoir comment accéder à la ressource.

Un sous-ensemble d’URI peut être directement utilisé pour localiser la ressource, c’est-à-dire trouver sur quel serveur se trouve la ressource et comment y accéder. Il s’agit d’une URL (Uniform Resource Locator) bien connue utilisée par les navigateurs Web.

Le schéma http est bien pratique car il peut se lire également comme un URL. Ce schéma donne :

• Le protocole à utiliser pour accéder à la ressource (http),
• L’autorité qui indique l’adresse du serveur (et son port),
• Et enfin, le chemin d’accès de ce que l'on va demander au serveur et qui peut parfois correspondre à une arborescence de fichiers sur un serveur.

Le principe REST permet de concevoir des serveurs évolutifs. Un serveur doit être sans état, ce qui signifie qu’il ne conserve pas d’information après avoir répondu à une demande d’un client. Cela permet de simplifier le traitement dans le serveur qui doit traiter les requêtes d'un grand nombre de clients.

Cela impose que l’état soit situé du côté du client. Cet état est alimenté à partir des données structurées que le client reçoit du serveur. Ainsi, lorsqu’un client demande une page Web, celle-ci peut contenir d’autres URI pour la compléter, par exemple des images, des feuilles de style, des scripts, etc.

Le client doit comprendre les données que le serveur lui envoie et donc connaître le format de représentation de la ressource qu'il reçoit pour y retrouver les URI. Pour cela, en plus de la ressource elle-même, le serveur ajoute des informations complémentaires, appelées métadonnées. Elles intègrent entre autres le format du contenu (content format). Il peut s’agir de texte pur, d’une image ou d’un format de texte structuré tel que HTML ou JSON.

HTTP est un protocole qui peut être utilisé pour mettre en œuvre un serveur Web les principes de REST (qualifié en anglais de RESTfull). HTTP définit différentes méthodes permettant au client d’interagir avec les ressources sur le serveur :

• GET est utilisée pour récupérer la représentation d’une ressource (par exemple : page Web, valeur de température d’un capteur, etc.) ;
• HEAD est utilisée pour récupérer uniquement les métadonnées présentes dans les en-têtes de réponse sans le corps de réponse ;
• POST est utilisée pour indiquer au serveur une nouvelle ressource ;
• PUT est utilisée pour stocker une ressource à l’endroit identifié par l’URI dans la requête. Si la ressource existe déjà, elle sera modifiée ;
• PATCH permet au client de ne modifier qu’une partie de la ressource ;
• DELETE est utilisée pour supprimer la ressource définie.

Il existe d’autres formalismes que REST. Un autre formalisme, très populaire, est orienté “diffusion” en utilisant le principe ”publication/abonnement” ou ”publish/subscribe”. Comme nous allons le montrer dans la suite, même si les fonctionnalités entre ces deux modes peuvent sembler similaires, la philosophie de conception est très différente : publish/subscribe vise des applications intégrées tandis que REST vise l’interopérabilité globale.

Le modèle publish/subscribe permet le découplage entre l’expéditeur d’un message et son destinataire. Dans ce paradigme (cf. schéma ci-dessus), il existe des ”Publishers” qui produisent des données ou des messages et envoient le message à une entité généralement appelée ”Broker”. En outre, les messages peuvent être classés en ”Topics”, contenus ou types, etc. Ensuite, il existe des abonnés qui souscrivent au broker, par exemple à un topic donné, afin de recevoir les messages qui les intéressent, comme exposé dans le schéma.

Le broker peut alors utiliser des filtres pour envoyer uniquement ces messages aux abonnés du topic concerné. Il existe plusieurs protocoles Publish-Subscribe tels que MQTT ⁴⁾, AMQP ⁵⁾, JMS ⁶⁾ ou XMPP ⁷⁾.

MQTT est détaillé dans la suite du cours car il est très populaire pour la communication entre processus, mais également dans l’IoT.

Imaginons par exemple que plusieurs capteurs soient installés dans deux bâtiments A et B. Certains capteurs collectent des informations sur la température et d’autres collectent des informations sur l’humidité. Ces capteurs peuvent envoyer les données régulièrement à un broker central.

Les données peuvent être classées en différentes rubriques qui peuvent également être organisées de manière hiérarchique. Par exemple, le topic /sensor signifie “toutes les données de capteurs”, /sensor/buildingA/ signifie “des données de capteurs uniquement installées dans le bâtiment A”. En plus, /sensor/buildingA/temperature pourrait signifier “des données de capteurs de température installés uniquement dans le bâtiment A”.

Certains abonnés peuvent s’abonner aux messages en fonction de leur intérêt. Ainsi, un abonné intéressé uniquement par les données d’humidité du bâtiment B peut s’abonner au sujet /sensor/buildingB/humidity et le broker n’enverra que ces données à cet abonné.

Les principaux avantages du paradigme publish-subscribe par rapport au paradigme client-serveur, tels qu'inclus en REST, sont les suivants :

• Faible couplage entre émetteur et récepteur, le broker sert d'intermédiaire et stocke les informations ;
• Passage à l’échelle. Les données provenant d'une source ne sont émises qu'une fois par la source. Le broker les recopie vers tous les abonnés. Dans un mode client/serveur, les données doivent être émises par le serveur autant que fois que les clients le demandent.

L’absence de couplage entre l’expéditeur et le destinataire se fait en termes d’espace, de temps et de synchronisation. Celui qui publie les données a une tâche simplifiée. Il n'a pas à gérer ou connaître ceux qui les consomment, il n'a qu’à les envoyer au broker.

MQTT est très léger et conçu pour les périphériques de faibles puissances. Il a une très petite empreinte logicielle et est optimisé pour fonctionner dans les environnements à faible bande passante. Cela rend MQTT idéal pour les applications IoT. Malgré tout, l’usage de TCP et des très nombreux acquittements peut s’avérer lourds pour les équipements ou les réseaux très contraints. Une version plus légère basée sur UDP existe pour ces cas d’usage, mais elle est peu utilisée.

S'ils se ressemblent, les principes de nommage des topics MQTT et des URI REST sont complètement différents. Par rapport à MQTT, le chemin dans l'URI n'a pas de sémantique. Il a juste vocation à être unique. Il ne peut pas être utilisé pour agréger plusieurs sources d'information. Si deux capteurs publient respectivement sur les topics /sensor/buildingA/temperature et /sensor/buildingB/temperature, un subscriber peut s'abonner au topic /sensor/*/temperature pour recevoir toutes les mesures ; ce qui est impossible avec REST : il faudra autant de requêtes que de capteurs pour récupérer l'ensemble des mesures.

Les URI sont simplement uniques au monde par leur construction alors que les topics du MQTT sont spécifiques à une application. Un topic MQTT peut être interprété différemment par deux applications différentes. Cela ne permet pas une interopérabilité sémantique. Les abonnés doivent être construits avec une connaissance des topics utilisés par les publieurs.

1-Dans la pile protocolaire de l'internet, quels protocoles ont pour fonction d'aiguiller les paquets jusqu'à leur destination (2 réponses) ?

☐ Ethernet
☐ IEEE 802.15.5
☐ Wi-Fi
☑ IPv4
☑ IPv6
☐ UDP
☐ TCP
☐ MQTT
☐ HTTP
☐ CoAP
☐ XML
☐ JSON 

2-Quels sont les formats qui permettent de représenter des informations structurées (2 réponses) ?

☐ Ethernet
☐ IEEE 802.15.5
☐ Wi-Fi
☐ IPv4
☐ IPv6
☐ UDP
☐ TCP
☐ MQTT
☐ HTTP
☐ CoAP
☑ XML
☑ JSON 

3-Dans l'URI https://plido.net/unit/definition.html, quel est le schéma ?

https

Quelle est l'autorité ?

plido.net

◁ Précédent | ⌂ Sommaire | Suivant ▷