UPnP, comme son nom l'indique, est dérivé de PnP (Plug aNd Play), qui est une technologie qui permet de faciliter l'installation, la configuration et l'ajout de périphériques informatiques à un micro-ordinateur.
Universal Plug And Play (UPnP) étend cette simplicité en incluant l’ensemble du réseau informatique, permettant la découverte et le contrôle des périphériques, y compris les dispositifs et services en réseau, tels que les imprimantes connectées au réseau ou les équipements électroniques.
Avec UPnP, un périphérique peut joindre le réseau dynamiquement, obtenir une adresse IP, transmettre ses capacités, en savoir plus sur la présence et les capacités d'autres périphériques et tout cela automatiquement sans recourir à aucune configuration du réseau. Les périphériques peuvent par la suite communiquer avec les autres périphériques directement. De plus UPnP est indépendant de tout système d'exploitation, langage de programmation ou support physique.
Acteurs du protocole UPnP Il existe deux grandes parties dans un réseau UPnP : les périphériques et les points de contrôle.
Périphériques Un périphérique est un conteneur de services simples ou imbriqués. Cette information est stockée dans un document XML que le périphérique doit contenir. En addition à l'ensemble de services, la description liste aussi des propriétés (comme le nom du périphérique et icônes) associées à ce périphérique.
Le périphérique contient des services.
Un service est la plus petite unité de contrôle dans un réseau UPnP. Un service expose les actions et les modèles de son état avec des variables d'état. Par exemple, un service d'horloge peut être modélisé avec une variable d'état, current_time, qui définit l'état de l'horloge, et deux actions, set_time et get_time, qui permettent de contrôler le service. Semblable à la description du périphérique, cette information fait partie d'une description XML standardisé par le forum UPnP. Un pointeur (URL) de ces descriptions de service est contenu dans le document de description de l'appareil. Les dispositifs peuvent contenir de multiples services.
Un service dans un dispositif UPnP est constitué d'une table d'état, un serveur de contrôle et un serveur d'événements. La table d'état modèle l'état du service par le biais des variables d'état et les mises à jour lorsque l'état change. Le serveur de contrôle reçoit des demandes d'action (comme set_time), les exécute, met à jour la table d'état (des réponses et des retours). Le serveur d'événements publie des événements aux abonnés intéressés à tout moment l'état des changements de service. Par exemple, le service d'alarme incendie enverrait un événement aux abonnés intéressés lorsque son état passe à «sonner».
Points de contrôle Le point de contrôle est un contrôleur qui est capable de découvrir et de contrôler les périphériques. Après la découverte du périphérique le point de contrôle peut : récupérer la description du dispositif et obtenir une liste des services associés ; récupérer des descriptions de service pour les services intéressants ; invoquer des actions pour contrôler le service ; s'abonner au serveur d'événements du service. Chaque fois qu’il y a un changement de l'état du service, le serveur d'événements enverra un événement au point de contrôle. Il est prévu que le périphérique intègre la fonctionnalité de point de contrôle (mais aussi que le point de contrôle intègre celle de périphérique) pour permettre un véritable réseau Peer-to-Peer.
Les protocoles réseaux utilisés par UPnP Protocoles Spéciaux d’UPnP Contient UPnP vendors, UPnP Forum Working Committees et UPnP Drivers Architecture document qui définissent le plus haut niveau du protocole d’UPnP. TCP/IP UPnP se base sur les protocoles TCP/IP (TCP, UDP, IGMP, ARP et IP). HTTP, HTTPU (unicast), HTTPMU (multicast) HTTP est le cœur de UPnP. HTTPU (HTTPMU) est une variation du HTTP, ils sont utilisés pour envoyer les messages au-dessus d’UDP/IP au lieu de TCP/IP. Tous les protocoles sont utilisés par SSDP. Ces protocoles sont utilisés comme multicast quand l’envoi du message n’a pas besoin de garantie. SSDP (Simple Service Discovery Protocol) il permet de découvrir les services sur le réseau. Il repose sur HTTPU et HTTPMU. Il définit les méthodes du point de contrôle pour trouver les périphériques intéressants. En conséquence, tous les points de contrôle ont les informations complètes du réseau. Le point contrôle et le périphérique utilisent SSDP. Un point qui vient de démarrer, va envoyer une requête de recherche en utilisant le protocole SSDP (via HTTPMU) pour trouver les périphériques et les services. Mais il peut aussi rechercher juste un type de périphériques ou un service particulier. Un périphérique UPnP écoute sur le port multicast. S’il reçoit une requête de recherche, il la vérifie pour décider si elle est bonne ou pas. Si elle est bonne, une réponse de l’unicast SSDP (via HTTPU) va être envoyée au point contrôle. SSDP est utilisé aussi pour publier les services. GENA (Generic Event Notification Architecture) Il permet d’envoyer et de recevoir les notifications en utilisant HTTP via TCP/IP et le multicast UDP. Il définit aussi les concepts entre les souscripteurs et les éditeurs de notifications pour permettre d’annoncer les événements. Le format de GENA est utilisé en UPnP pour créer les annonces de la présence, et l’envoi de celles-ci en utilisant SSDP. Il permet aussi de souscrire au service de l’événement. SOAP (Simple Object Access Protocol) ce protocole repose sur l'envoi de messages XML sur HTTP pour exécuter des services à distance. Il est devenu le standard pour RPC basé sur la communication sur Internet. Il peut fonctionner efficacement à travers un pare-feu et un mandataire. Le point de contrôle utilise SOAP pour envoyer les messages aux périphériques et recevoir des résultats ou des erreurs. Chaque requête du point de contrôle contient les actions avec des paramètres dedans. La réponse contient les valeurs des paramètres. XML (Extensible Markup Language) Il utilise la définition W3C qui est le format universel pour construire les données sur Web.
Description des six étapes d'UPnP
Étape 1 : Adressage Les points de contrôles et les périphériques cherchent un serveur DHCP pour se procurer une adresse IP. Si aucun serveur DHCP n'est disponible, Auto-IP est utilisé pour obtenir une adresse. Les équipements envoient un message DHCPDISCOVER via DHCP. Si un DHCPOFFER est reçu les équipements continuent le processus d’obtention dynamique d’une adresse IP, sinon, ceux-ci doivent utiliser un Auto-IP.
Pour configurer automatiquement une adresse IP, les équipements utilisent un algorithme aléatoire pour choisir une adresse en 169.254/16. L’adresse sélectionnée doit être testée pour savoir si elle est déjà utilisée, si tel est le cas il faut choisir une autre adresseUPnPArchitecture, page 8.
Pour le test les équipements envoient des requêtes ARP avec leur adresse IP pour voir si d’autres équipements utilisent cette adresse. Si une réponse est reçue, c’est que l’adresse est déjà utilisée et doit donc être modifiée. Ensuite, les équipements envoient encore 2 requêtes ARP pour être sûr que d’autres équipements ne gardent pas des caches ARP avec l’adresse IP qui a pu être utilisée par un autre équipement. Après avoir acquis une adresse IP, les équipements doivent tester régulièrement la présence du serveur DHCPUPnPArchitecture, page 9..
Étape 2 : Découverte Fichier:UPnP discovery phase.jpg Dans la découverte, le périphérique fait ce qu’on peut appeler de la publicité. Il envoie un message NOTIFY à tous les points de contrôles en utilisant UDP. NOTIFY * HTTP/1.1 HOST: 239.255.255.250:1900 CACHE-CONTROL: max-age = (la durée d’expiration de la publicité) LOCATION: (l’URL du périphérique) NT: search target (type de la publicité( concernant le périphérique ou un service)) NTS: ssdp:alive (sous-type ssdp:alive pour les publicités et ssdp : byebye pour quitter) USN: (identifiant unique pour la publicité) Après cela, le point de contrôle recherche le périphérique ou le service. Il envoie un message M-SEARCH.
M-SEARCH * HTTP/1.1 HOST: 239.255.255.250:1900 MAN: (ssdp:discover) MX: (temps d’attente) ST: (type d’élément recherché à compare avec NT)
Et pour finir le périphérique envoie un message de réponse au point de contrôle (HTTP/1.1 200 OK) si le paramètre NT correspond à ST. HTTP/1.1 200 OK CACHE-CONTROL: max-age = ( la durée d’expiration de la publicité) LOCATION: (l’URL du périphérique) ST: (type d’élément recherché) USN: (identifiant unique pour la publicité)
Les 3 requêtes utilisent le protocole SSDP.
Étape 3 : Description À partir de l'argument LOCATION qui contient l'URL du périphérique, le point de contrôle peut accéder à un fichier XML qui contient plusieurs informations sur le périphérique et sur ses services. Il y a deux parties dans la description d’un périphérique : la description physique et la description logiqueUPnPArchitecture, page 37.. La description de services informe sur les capacités du périphérique. Obtenir la description du périphérique est simple : le point de contrôle envoie une requête HTTP GET à l’URL contenu dans le message de découverte (idem pour avoir la description du service). Les documents de description doivent être envoyés en utilisant l'adresse IP contenue dans la réponse à la requête HTTP GET. Si un périphérique a besoin de changer certaines de ses descriptions, il doit quitter la publicité et republier ensuite. Par conséquent, le point de contrôle peut détecter un changement de description à la suite de l'apparition d'un périphérique dans le réseau ; il suffit pour cela qu’il vérifie la présence de la variable CONFIGID.UPNP.ORG dans la publicitéUPnPArchitecture, page 38..
Format d’un message HTTP GET :
HTTPget GET /descriptionPath HTTP/1.1 HOST: hostname:portNumber ACCEPT-LANGUAGE: language preferred by control point (optionnel)
Format d’un message HTTP REQUEST :
HTTP/1.1 200 OK CONTENT-LANGUAGE: language used in description CONTENT-LENGTH: bytes in body CONTENT-TYPE: text/xml; charset="utf-8" DATE: when responded
BODY(La description détaillée du service ou du périphérique)
Étape 4 : Contrôle Fichier:Controle.jpg Un point de contrôle envoie l’action au service du périphérique. Lorsque l’action a été exécutée (ou lorsqu'elle a échoué), le service retourne des résultats ou éventuellement des erreurs. Il envoie un message de contrôle à l’URL de contrôle présente dans la description du périphérique. Le service retourne des résultats. Les effets de l’action changent les variables d’états du service. Quand ces variables changent, des événements sont publiés à tous les points de contrôle qui sont intéressés. Tant que les publicités d’un périphérique n’ont pas expiré, le point de contrôle considère que celui-ci est toujours fonctionnelUPnPArchitecture, page 67.. Les points de contrôle doivent utiliser l'encodage UTF-8 pour tous les messages de contrôle et les réponses. Si beaucoup d’informations doivent être envoyées en association de l’action, il n’est pas recommandé de les envoyer dans les arguments de SOAP. Il est possible par exemple d'envoyer l’URL en argument et d'utiliser les méthodes HTTP GET, PUT or POST pour transférer les données. L'encodage de transfert en bloc peut être utilisé si la quantité de données n’est pas connue à l’avance. Cet encodage permet de transmettre la ressource par morceaux consécutifs en précédant chacun par une ligne de texte donnant la taille de celui-ci en hexadécimal. Le transfert se termine alors par un morceau de taille nulle, où des en-têtes finaux peuvent être envoyésUPnPArchitecture, page 68.. Les en-têtes supplémentaires liés à cet encodage de transfert sont : Transfer-Encoding Spécifie l'encodage de transfert. La seule valeur définie par la spécification est "chunked". Trailer Liste toutes les en-têtes figurant après le dernier morceau transféré.