Fonctionnalités de WS-Discovery supplémentaires

Dans certains cas, le profil d’appareils pour les services web (DPWS) et les spécifications associées ne définissent pas explicitement les fonctionnalités d’implémentation. Par exemple, la spécification WS-Discovery ne définit pas le comportement du client et de l’hôte dans les environnements multi-accueil. Lorsque WSDAPI a été implémenté, certaines fonctionnalités de découverte ont été ajoutées au-delà des fonctionnalités définies dans la spécification.

WSDAPI implémente également les parties sélectionnées de WS-Discovery v1.1 CD1 pour communiquer avec un proxy de découverte via HTTP.

L’objectif de cette rubrique est de décrire les fonctionnalités de découverte implémentées par WSDAPI, mais pas autrement décrites dans les spécifications DPWS ou WS-Discovery.

Adresses IPv6 et format d’URI soap.udp

SOAP-over-UDP et WS-Discovery ne décrivent pas explicitement comment une adresse IPv6 littérale est représentée au format URI soap.udp. RFC 2396, intitulé « Uri (Uniform Resource Identifiers) : Syntaxe générique », indique que les adresses IPv6 littérales ne sont pas prises en charge par le format d’URI soap.udp.

Par souci de simplicité, WSDAPI reconnaît les adresses IPv6 placées entre crochets dans le schéma soap.udp. Par exemple, l’adresse soap.udp://[2001:abcd:0001:0002:0003:0004:0005:0032]:3702 est reconnue par WSDAPI. Cela est similaire à la façon dont les adresses IPv6 sont gérées dans HTTP.

Hello et XAddrs

L’objet d’hébergement DPWS de WSDAPI n’envoie jamais de message WS-Discovery Hello avec XAddrs dans le corps du message. Un client envoie toujours un Résoudre message après avoir reçu un message Hello si le client doit obtenir les XAddrs.

Il existe deux avantages de cette approche. Tout d’abord, un appareil basé sur WSDAPI n’expose jamais les XAddrs qui divulguent les adresses IP des réseaux privés. Deuxièmement, un appareil basé sur WSDAPI expose uniquement les XAddrs accessibles au client, ce qui signifie que les adresses IPv6 ne sont jamais envoyées à un client IPv4.

Lorsqu’un sonde ou résoudre le message est reçu, seul un seul XAddr est envoyé en réponse. Le XAddr envoyé correspond à l’adresse locale sur laquelle la demande a été reçue. Si la demande a été reçue entre les sous-réseaux via IPv6, WSDAPI fournit une adresse IPv6 globale dans la réponse.

Adresses préférées

Un appareil peut fournir plusieurs XAddrs dans un Hello, ProbeMatchou message ResolveMatch. Un service peut également être disponible sur plusieurs points de terminaison avec différentes adresses de transport. Dans ces cas, WSDAPI tente de communiquer avec l’appareil sur la première adresse utilisable qu’il trouve. Une adresse est utilisable s’il provient d’un protocole disponible, tel que IPv4 sur un ordinateur sur lequel IPv4 est installé ou IPv6 sur un ordinateur où IPv6 est installé. En outre, si l’adresse provient d’un appareil ou d’un service qui ne se trouve pas sur le sous-réseau local, il est utilisable uniquement s’il s’agit d’IPv4, de site IPv6 local ou de lien IPv6 local.

WSDL dans l’échange de métadonnées

Les appareils et services basés sur WSDAPI ne fournissent pas leur WSDL dans l’échange de métadonnées, sauf si l’application l’étend pour fournir ces informations. Par défaut, le provisionnement WSDL ne fait pas partie du modèle de programmation.

APP_MAX_DELAY

DPWS définit APP_MAX_DELAY, intervalle aléatoire entre la réception d’un de sonde et l’envoi d’un ProbeMatch, comme 5 000 millisecondes. Le Pare-feu Windows nécessite que le modèle de réponse de requête/monodiffusion de multidiffusion pour UDP fonctionne uniquement dans la fenêtre de pare-feu de 4 secondes. Par conséquent, WSDAPI transmet les réponses en 2 500 ms ou moins, au lieu de la fenêtre de 5 000 ms décrite par APP_MAX_DELAY.

Réservations de ports IANA

WSDAPI utilise le port TCP 5357 pour le trafic HTTP et le port TCP 5358 pour le trafic HTTPS par défaut. Ces ports sont réservés aux processus de privilège inférieur via une réservation d’URL dans HTTP.sys, et sont également réservés avec IANA.

Partage de ports UDP

WSDAPI utilise le partage de ports. Les messages de monodiffusion envoyés au port 3702 peuvent ne pas être gérés correctement par toutes les applications WSDAPI. Si une application se lie exclusivement au port 3702, elle peut empêcher les applications WSDAPI d’utiliser ce port correctement.

WS-Discovery proxy CD1 v1.1

WSDAPI recherche et communique avec un proxy de découverte qui implémente le protocole en mode managé CD1 WS-Discovery v1.1. WS-Discovery v1.1 CD1 est la première révision de WS-Discovery pour inclure une description explicite d’un protocole HTTP pour la communication entre un proxy et un client ou un appareil.

Pour limiter le nombre de versions simultanées utilisées dans les demandes de multidiffusion, WSDAPI envoie une requête de sonde WS-Discovery dans l’espace de noms 2005/04, mais recherche le type discoveryProxy WS-Discovery v1.1 CD1. Si un proxy répond, WSDAPI envoie une requête HTTP Probe ou Resolve au point de terminaison proxy spécifié tel que défini dans WS-Discovery v1.1 CD1.