Modèle de la pile des protocoles réseau dans UPnP

Les protocoles TCP/IP et HTTP fournissent la connexion réseau ambiant de base pour l'architecture de dispositifs UPnP. Chaque dispositif fournit un ensemble d’URLs HTTP pour que les points de contrôle puissent rechercher le document de description du dispositif, contrôler le dispositif, souscrire aux événements, et obtenir une page de présentation des dispositifs. L'architecture UPnP permet qu’un serveur communique avec plusieurs destinataires simultanément. À cet égard, l'architecture UPnP

emploie un message HTTP qui est envoyé sur une connexion réseau unicast ou multicast. La Figure 54 montre la pile de protocoles employés par UPnP. On observe que les communications ambiantes peuvent être réalisées en utilisant des réseaux de communication Ethernet ou Wifi sur les protocoles IP. La découverte des dispositifs est réalisée sur le protocole UDP (User Datagram Protocol). La description des dispositifs et leurs services, et la gestion des événements, sont réalisés en mode connecté par le protocole TCP (Transmission Control Protocol) tandis que les mécanismes de découverte font appel à UDP. Chaque fonctionnalité au sein d’UPnP a besoin de protocoles spécifiques tels que SSDP, SOAP et GENA. Ils seront expliqués dans les sections suivantes de ce manuscrit.

Des applications UPnP

HTTPMU La découverte HTTPU La découverte HTTP Les événements IP UDP TCP SSDP GENA SSDP GENA HTTP La description SOAP Le contrôle Les spécifications du Forum UPnP Les spécifications des constructeurs des dispositifs

Ethernet Wifi

Figure 54 : Pile de protocoles réseau dans UPnP.

3.5.4.1 HTTP multicast et HTTP unicast

L’architecture UPnP est basée sur le protocole de communication informatique client - serveur HHTP (HyperText Transfer Protocol). Egalement, UPnP utilise IP unicast ou multicast comme moyen de transport pour envoyer des messages, en temps réel, vers un destinataire ou plusieurs destinataires respectivement. Un point de contrôle utilise un mécanisme de découverte de service basé sur IP multicast afin de rechercher les dispositifs présents sur le réseau ambiant. Un dispositif annonce sa présence sur le réseau ambiant en utilisant des messages sur IP multicast. Les services envoient des notifications d’événements sur IP multicast vers les points de contrôle qui ont souscrit pour les recevoir.

Dans UPnP, la communication unicast et multicast est faite en utilisant le protocole HHTP sur UDP (User Datagram Protocol) au lieu de TCP (Transmission Control Protocol). La communication sur UDP est plus rapide que la communication sur TCP. Par exemple, avec HTTPU sur UDP unicast, un dispositif peut envoyer un message HHTP vers un point de contrôle plus rapidement qu’en utilisant une connexion TCP. HTTPMU sur UDP multicast permet d’envoyer des messages HTTP à plusieurs destinataires (groupe) simultanément. Chaque serveur, appartenant au groupe logique de communication, partage une adresse commune de multicast avec le but de recevoir les données envoyées à cette adresse. Un mécanisme permet aux serveurs de joindre ou non ce groupe. Les dispositifs et points de contrôle UPnP utilisent l’adresse multicast 239.255.255.250 et le port 1900. En

utilisant cette adresse et port, il est possible qu’un dispositif quelconque puisse envoyer des données simultanément vers les autres dispositifs et points de contrôle connectés au réseau ambiant.

3.5.4.2 XML (Extensible Markup Language)

XML est un méta langage qui sert de base pour créer des langages balisés afin de structurer des données [W3C, 2004]. Il utilise des balises et des attributs pour décrire les données d’une manière hiérarchique. XML est employé par l'architecture UPnP pour décrire les dispositifs et les services qu'ils fournissent, pour exprimer les contenus des messages entre dispositifs, et pour spécifier le format des messages d’événements envoyés par les services aux points de contrôle.

3.5.4.3 SSDP (Simple Service Discovery Protocol)

SSDP est le protocole de découverte de services utilisé par l’architecture UpnP, qui ne nécessite ni configuration, ni gestion administrative, ni intervention humaine pour son fonctionnement. Pour identifier un service, SSDP utilise deux concepts : le service type et l’Unique Service Name (USN). Le service type est un identifiant URI (Uniform Resource Identifier) permettant de connaître la fonction d’une ressource particulière.

Un URI est une chaîne de caractères permettant d'identifier une ressource abstraite ou physique accessible sur Internet. La syntaxe des URIs a été définie par Tim Berners-Lee et décrite en détail en août 1998 dans la RFC 2396 (Request For Comment) de l'IETF (Internet Engineering Task Force). Exemple d’URI : http://193.50.39.120:8080/objet/description.xml.

Les URLs (Uniform Resource Location) identifient une ressource par le moyen de leur chemin d'accès et précisent donc leur situation sur le réseau ("location"). Comme les URL ont été le premier type d'URI répandu, le sigle URL a parfois été utilisé en lieu et place du concept d'URI.

L’USN est un URI permettant d’associer un nom unique aux services pour les différencier des services du même type. Un USN typiquement contient un UUID (Universally Unique Identifier) utilisé pour identifier uniquement un objet.

Il y a deux types de requêtes SSDP. La première, est une requête pour découvrir les ressources dans le réseau et la deuxième est une requête pour annoncer la présence d'une ressource dans le réseau ambiant. SSDP utilise HTTP sur UDP multicast (HTTPMU) pour envoyer des messages à tous les points SSDP sur le réseau ambiant. Les points de contrôle, représentant les clients SSDP, effectuent des requêtes de recherche afin de découvrir les dispositifs et leurs services à l’adresse 239.255.255.250 :1900, laquelle est réservée pour la communication multicast. Un dispositif, ou ressource SSDP, écoute le canal multicast pour s’informer sur les requêtes de découverte. Si un dispositif, reçoit une requête de découverte HTTPMU multicast qui est adapté aux services offerts, il répond en envoyant une réponse directe au client SSDP (point de contrôle) qui a initié la recherche, en utilisant HTTPU unicast. Un point de contrôle peut reformuler sa recherche de manière plus précise dans le but de trouver des dispositifs ou des services particuliers en utilisant des mécanismes de recherche adaptés pour trouver tous les dispositifs, les dispositifs racines seulement et un type de dispositif, ou bien, un service déterminé. Il y a deux types de notifications : l’arrivée d’un dispositif et le départ d'un dispositif. SSDP utilise des méthodes de notification GENA sur HTTPMU. Lorsqu’un dispositif est inséré dans le réseau, il envoie en mode multicast (HTTPMU) des messages annonçant les services

qu’il supporte. Lorsqu’un dispositif est enlevé du réseau, les points de contrôle sont informés au moyen d’un message de notification GENA sur HTTPMU.

3.5.4.4 SOAP (Simple Object Access Protocol)

SOAP [W3C, 2003] est un protocole qui rassemble XML et HHTP afin de transmettre des messages sur HTTP et fournir un mécanisme permettant de faire des appels de procédures sur un ordinateur distant, selon une méthode nommée RPC (Remote Procedure Call). XML est employé pour exprimer les contenus des messages SOAP, alors que le HTTP est employé pour envoyer des messages à leur destination. Le corps d’un message SOAP contient une méthode d’appel à distance avec ses arguments associés, une méthode de réponse et l'information d'erreur pour des appels échoués. Chaque requête envoie par un point de contrôle est détaillée à l'intérieur d’un message SOAP, y compris le nom de l'action à invoquer et les arguments qui sont associés à l'action. Ceci fait, un service envoie au point de contrôle un message contenant la valeur de réponse retournée par l’action et les arguments. En cas d'erreur, le service retourne un message d'erreur au point de contrôle en indiquant le code d'erreur.

3.5.4.5 GENA (Generic Event Notification Architecture)

Les composants d'un système réparti communiquent généralement en utilisant deux mécanismes différents : le RPC et la notification d'événements. En RPC, les objets attendent passivement pour fournir des services aux clients. Cependant, avec la notification d'événements, les changements d’état du système sont modélisés comme des événements, permettant aux objets, informés de ces changements, de s’adapter dynamiquement afin d’obtenir un comportement global plus efficient. GENA est un protocole pour la gestion des publications et souscriptions aux notifications d’événements en utilisant HTTP. Le protocole GENA utilise HHTPMU sur UDP multicast pour notifier la présence d’un dispositif avec le protocole SSDP. GENA utilise HHTTP sur TCP/IP pour signaler les changements d’état d’un service lors de la gestion d’événements UPnP. Les messages de notification contiennent le nom d’une ou plusieurs variables et la valeur actuelle de ces variables, formatées en langage XML. Un point de contrôle, intéressé par la réception de notifications d’événements, doit souscrire à une source d’événements en envoyant une requête qui inclut le service intéressé, la localisation du dispositif (qui envoie les événements) et une durée de souscription. En utilisant GENA, une souscription peut-être renouvelée périodiquement, ou bien être annulée.