Protocole UPnP

Pour consulter un article plus général, voir : UPnP.

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 à un micro-ordinateur.

Universal Plug And Play (UPnP) étend cette simplicité en incluant l’ensemble du réseau, 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^[1].

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 icones) 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, et 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 le 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, IGMP 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 de l’UDP/IP au lieu de TCP/IP. Tous les protocoles sont utilisés par SSDP. Ces protocoles sont utilisés comme multicast quand l’envoie du message n’a pas besoin de garantie.

SSDP (Simple Service Discovery Protocol) 

Il permet de trouver les services sur le réseau. Il est basé sur HTTPU et HTTPMU. Il définit les méthodes du point de contrôle pour trouver les périphériques intéressants. Par conséquent tous les points contrôles 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’envoie de celles-ci en utilisant SSDP. Il permet aussi de souscrire au service de l’événement.

SOAP (Simple Object Access Protocol) 

Il définit l’usage de XML et HTTP pour exécuter les instructions à distance. Il est devenu le standard pour RPC basé sur la communication sur Internet. Il peut fonctionner efficacement avec Firewall et Proxy. 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 est un message qui 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

Automate général

Fichier:AutomateFinal.jpg

Etape 1 : Adressage

Les points de contrôles et les périphériques cherchent un serveur DHCP pour se procurer une adresse IP si celui-ci est disponible, sinon ils utilisent Auto-IP 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 adresse^[2]
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 il faut donc la changer. Après cela, les équipements envoient encore 2 requêtes ARP cette fois ci pour être sur que d’autres équipements ne gardent pas des caches ARP avec l’adresse IP qui a pu être utilisé par un autre équipement.
Après avoir acquis une adresse IP les équipements doivent tester régulièrement la présence du serveur DHCP^[3].

Etape 2 : Découverte

Dans la découverte, le périphérique fait ce qu’on peut appeler de la publicité. Il envoi 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 envoi 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 envoi 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.

Etape 3 : Description

A 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 logique^[4].
La description de services informe sur les capacités du périphérique.
Avoir 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 (même chose pour avoir la description du service).
Les documents de description doivent être envoyés en utilisant la même adresse IP contenu dans la requête http GET.
Si un périphérique a besoin de changer certaines de ses descriptions, il doit quitter la publicité et republié après.
Par conséquence, le point de contrôle peut détecter si la description est changée après qu’un périphérique réapparait dans le réseau, il suffit qu’il regarde si la variable CONFIGID.UPNP.ORG est présente la publicité^[5].
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é du service ou du périphérique)

Etape 4 : Contrôle

Un point de contrôle envoie l’action au service du périphérique, après quand l’action est exécutée(ou échouée) le service retourne des résultats ou éventuellement des erreurs.
Donc il envoie un message de contrôle à l’URL de contrôle obtenu de 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ôles qui sont intéressés. Tant que les publicités d’un périphérique n’ont pas expiré le point de contrôle sait que celui-ci est toujours fonctionnel^[6]. Les points de contrôles doivent utilisés UTF-8 pour tous les messages de contrôle et les réponses.
Si on a beaucoup d’informations à envoyer en association de l’action, il n’est pas recommandé de les envoyées dans les arguments de SOAP, on pourra par exemple envoyer l’URL en argument et utiliser un http GET, PUT or POST pour transférer les données. HTTP chunked peut être utilisé si la quantité de données n’est connue à l’avance : L'encodage de transfert nommé chunked 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és^[7]. 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 RFC 2616 est chunked.

Trailer 

Liste tous les en-têtes figurant après le dernier morceau transféré.

TE 

Envoyé par le client pour spécifier les encodages de contenu supportés (Content-Encoding, ne pas confondre avec Transfer-Encodingw/code> car chunked est obligatoirement supporté par les clients et serveurs implémentant le standard HTTP/1.1), et spécifie si le client supporte l'en-tête Trailer en ajoutant trailers à la liste.

Protocoles utilisés lors du contrôle :

Dans la couche la plus élevée, les messages de contrôles contiennent d’abord les informations du constructeur (valeurs des arguments), en descendant on retrouve aussi les informations du UPnP Forum (noms d’actions, noms d’argument, les noms de variables). Les messages sont formatés utilisant les entêtes et body Simple Object Access Protocol (SOAP) et les messages sont délivrés via http (TCP, IP).Les messages de contrôle utilisent la méthode POST^[8].

Exemple d’invocation de message:

POST path control URL HTTP/1.0
HOST: hostname:portNumber
CONTENT-LENGTH: bytes in body
CONTENT-TYPE: text/xml; charset="utf-8"
USER-AGENT: OS name/OSversion UPnP/1.1 productName/versionName
SOAPACTION: "urn:schemas-upnp-org:service:serviceType:v#actionName"
<?xml version="1.0"?>
<s:Envelope
xmlns:s="http://schemas.xmlsoap.org/soap/envelope/"
s:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/">
<s:Body>
<u:actionName xmlns:u="urn:schemas-upnp-org:service:serviceType:v">
<argumentName>in arg value</argumentName>
<!-- other in args and their values go here, if any -->
</u:actionName>
</s:Body>
</s:Envelope>

Donc pour expliquer un peu les éléments de ce message : HOST : hostname (nom de domaine ou l’adresse IP) et un port optionnel. Si le port est vide ou n’est pas donné on met le port 80. USER-AGENT : exemple « unix/5.1 UPnP/1 .1 MyProduct/1.0 »

Pour les <argumentName> est requis seulement si l’action a des arguments. Et pour chaque argument il faut rajouter un autre champ<argumentName>.

Format d’une réponse à une action :

HTTP/1.0 200 OK
CONTENT-TYPE: text/xml; charset="utf-8"
DATE: when response was generated
SERVER: OS/version UPnP/1.1 product/version
CONTENT-LENGTH: bytes in body
<?xml version="1.0"?>
<s:Envelope
xmlns:s="http://schemas.xmlsoap.org/soap/envelope/"
s:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/">
<s:Body>
<u:actionNameResponse xmlns:u="urn:schemas-upnp-org:service:serviceType:v">
<argumentName>out arg value</argumentName>
<!-- other out args and their values go here, if any -->
</u:actionNameResponse>
</s:Body>
</s:Envelope>

Messages d’erreurs :

HTTP/1.0 500 Internal Server Error
CONTENT-TYPE: text/xml; charset="utf-8"
DATE: when response was generated
SERVER: OS/version UPnP/1.1 product/version
CONTENT-LENGTH: bytes in body
<?xml version="1.0"?>
<s:Envelope
xmlns:s="http://schemas.xmlsoap.org/soap/envelope/"
s:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/">
<s:Body>
<s:Fault>
<faultcode>s:Client</faultcode>
<faultstring>UPnPError</faultstring>
<detail>
<UPnPError xmlns="urn:schemas-upnp-org:control-1-0">
<errorCode>error code</errorCode>
<errorDescription>error string</errorDescription>
</UPnPError>
</detail>
</s:Fault>
</s:Body>
</s:Envelope>

Donc pour les <errorCode> et <errorDescription> on peut voir leurs différentes valeurs dans le tableau suivant :

Etape 5 : Évènement

Pour souscrire au serveur d’événement, le point de contrôle envoie un message de souscription (qui contient l’URL du périphérique, l’identificateur du service et une URL pour la délivrance des messages)^[9].
Si la souscription est acceptée le périphérique réponds avec une durée pour la souscription et un identificateur unique pour celle-ci (concernant la durée de souscription elle doit être choisie suivant la présence du point de contrôle dans le réseau par exemple s’il quitte le réseau fréquemment chaque minute la durée doit être courte éventuellement).
Pour garder la souscription active, le point de contrôle doit renouveler la souscription avant qu’elle n’expire, dans ce cas le message de renouvellement ne contient plus l’URL de délivrance mais il contient l’identificateur de souscription, la réponse est la même que pour celle du message de souscription).
Si le point de contrôle n’a plus besoin d’être informer des événements, il doit envoyer un message cancel pour quitter la souscription.
Les messages d’événements, les noms des variables d’état et les valeurs courantes sont exprimés en XML.
Le premier message d’événement concernant la demande de souscription contient les noms et valeurs des variables d’état et permet au point de contrôle d’initialiser son modèle de l’état du service(le premier message est toujours envoyé même si le point de contrôle quitte la souscription).
Notons que il y a des variables qui changent trop rapidement ou qui contiennent des valeurs très larges pour que la notification d’événement soit utile. Dans ce cas il faut filtrer ou modérer le nombre de messages d’événement, le service désigne une ou plusieurs variables d’état comme étant non notifiés.
Il faut savoir aussi que le périphérique dispose d’une liste avec les souscripteurs (points de contrôle) et si la souscription est expiré l’identifiant de souscription est invalide et le périphérique efface le point de contrôle de cette liste et n’envoie plus aucune notification à celui-ci, et si le point de contrôle essaye d’envoyer un message n’importe lequel il sera négligé par le périphérique.
Il est fortement conseillé que les points de contrôle surveillent constamment les messages publicités des périphériques comme ça si un périphérique quitte le réseau le point de contrôle saura que sa souscription est terminé^[10]. Pile de protocoles pour la notification d’événement :


Dans la couche supérieure on retrouve les messages de souscription et d’événements contiennent les informations du constructeur comme les URL pour la souscription et la durée des souscriptions ou des valeurs de variables spécifiques. En descendant plus bas dans les couches on retrouve les informations d’UPnP Forum comme les identificateurs des services et des noms de variables. Comme pour les messages de contrôles on utilise http via TCP/IP^[11].
Formats des messages :

Message de demande de souscription 

SUBSCRIBE publisher path HTTP/1.1
HOST: publisher host:publisher port
USER-AGENT: OS/version UPnP/1.1 product/version
CALLBACK: <delivery URL>
NT: upnp:event
TIMEOUT: Second-requested subscription duration(Integer)

Réponse au message de souscription 

Notez que dans l'exemple ci-dessous, le champ SID n'est est pas utilisé pour la première souscription.

HTTP/1.1 200 OK
DATE: when response was generated
SERVER: OS/version UPnP/1.1 product/version
SID: uuid:subscription-UUID
CONTENT-LENGTH: 0
TIMEOUT: Second-actual subscription duration

Pour un renouvellement de souscription 

SUBSCRIBE publisher path HTTP/1.1
HOST: publisher host:publisher port
SID: uuid:subscription UUID ( identificateur de souscription)
TIMEOUT: Second-requested subscription duration

Pour quitter une souscription :

UNSUBSCRIBE publisher path HTTP/1.1
HOST: publisher host:publisher port
SID: uuid:subscription UUID (identificateur de souscription)

Message de notification en mode (Unicast) 

NOTIFY delivery path HTTP/1.0
HOST: delivery host:delivery port
CONTENT-TYPE: text/xml; charset="utf-8"
NT: upnp:event
NTS: upnp:propchange
SID: uuid:subscription-UUID
SEQ: event key
CONTENT-LENGTH: bytes in body
<?xml version="1.0"?>
<e:propertyset xmlns:e="urn:schemas-upnp-org:event-1-0">
<e:property>
<variableName>new value</variableName>
</e:property>
<!-- Other variable names and values (if any) go here. -->
</e:propertyset>

Message de réponse à la notification d’événements 

Concernant ce message envoyé par le point de contrôle, s'il n’est pas envoyé en 30 secondes le périphérique abandonne l’envoie de la notification mais garde toujours la souscription active pour une future notification d’événement.

HTTP/1.1 200 OK

Notification Multicast 

 
NOTIFY * HTTP/1.0
HOST: 239.255.255.246:7900 *** note the port number is different than SSDP ***
CONTENT-TYPE: text/xml; charset="utf-8"
USN: Unique Service Name for the publisher
SVCID: ServiceID from SCPD
NT: upnp:event
NTS: upnp:propchange
SEQ: monotonically increasing sequence count
LVL: event importance
BOOTID.UPNP.ORG: number increased each time device sends an initial announce or update message
CONTENT-LENGTH: bytes in body
<?xml version="1.0"?>
<e:propertyset xmlns:e="urn:schemas-upnp-org:event-1-0">
<e:property>
<variableName>new value</variableName>
</e:property>
<!-- Other variable names and values (if any) go here. -->
</e:propertyset>

Pour le champ level voici un tableau présentant les différentes valeurs normalisées :

Valeur possible pour le champ LVL:

Valeur	description
upnp:/emergency	L’événement rapporte des informations critiques qui devraient entrainer une action immédiate du périphérique.
upnp:/fault	L’événement rapporte des informations relative à un cas d'erreur.
upnp:/warning	L’événement rapporte des informations qui ne sont pas critiques et que le périphérique devrait vouloir traité ou transmettre à l'utilisateur.
upnp:/info	L’événement rapporte des informations relatives au traitement normal d'une opération du périphérique qui pourrait intéresser l'utilisateur. Cette information ne rapporte aucune condition anormale relative à un statuts de type faute (i.e. fault) ou mise en garde(i.e. warning).
upnp:/debug	L’événement rapporte des informations typiquement utilisées par les programmeurs et les ingénieurs de test, pour évaluer l'état et les opérations internes réalisées par le périphérique. Ces informations ne sont pas destinées aux utilisateurs.
upnp:/general	Pour les événements qui ne correspondent à aucune autre catégorie.
<domaine>:/<level>	Exemple d'extension vendeur. le champ Domain est le domaine ICANN pour le vendeur et level est une chaine de caractère arbitraire définie par le vendeur. e.g. domain.org:/alerts/type/

Etape 6 : Présentation

Donc pour ouvrir la page de présentation le point de contrôle un HTTP GET et le périphérique répond avec un HTTP Response^[12].

Annexes

Références

1. ↑ Understanding UPnP 2000, p. 1
2. ↑ UPnPArchitecture, page 8.
3. ↑ UPnPArchitecture, page 9.
4. ↑ UPnPArchitecture, page 37.
5. ↑ UPnPArchitecture, page 38.
6. ↑ UPnPArchitecture, page 67.
7. ↑ UPnPArchitecture, page 68.
8. ↑ UPnPArchitecture, page 69.
9. ↑ UPnPArchitecture, page 84.
10. ↑ UPnPArchitecture, page 85.
11. ↑ UPnPArchitecture, page 86.
12. ↑ UPnPArchitecture, page 106.

Bibliographie

• (en) UPnP Device Architecture 1.1 : Document Revision Date 15 October 2008, [Forum], 15 octobre 2008, 136 p. [lire en ligne (page consultée le 25-11-2010)] 

• (en) Understanding Universal Plug and Play, [[1]], juin 2000, 42 p. [lire en ligne (page consultée le 25-11-2010)]