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 multilocataires. 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 des 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 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. La RFC 2396, intitulée « URI (Uniform Resource Identifiers) : Generic Syntax », indique que les adresses IPv6 littérales ne sont pas prises en charge par le format 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’enverra jamais de WS-Discovery message Hello avec XAddrs dans le corps du message. Un client envoie toujours un message Resolve après avoir reçu un message Hello si le client a besoin d’obtenir les XAddrs.

Cette approche présente deux avantages. Tout d’abord, un appareil basé sur WSDAPI n’exposera 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.

Quand un message Probe ou Resolve est reçu, un seul XAddr est envoyé en réponse. Le XAddr envoyé correspond à l’adresse locale à 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 message Hello, ProbeMatch ou ResolveMatch . Un service peut également être disponible sur plusieurs points de terminaison avec différentes adresses de transport. Dans ce cas, WSDAPI tente de communiquer avec l’appareil à la première adresse utilisable qu’il trouve. Une adresse est utilisable si elle provient d’un protocole disponible, tel que IPv4 sur un ordinateur sur lequel IPv4 est installé ou IPv6 sur un ordinateur sur lequel 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, elle n’est utilisable que si elle est IPv4, IPv6 site local ou 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 s’ils sont étendus par l’application pour fournir ces informations. Par défaut, l’approvisionnement WSDL ne fait pas partie du modèle de programmation.

APP_MAX_DELAY

DPWS définit APP_MAX_DELAY, l’intervalle aléatoire entre la réception d’une sonde et l’envoi d’un ProbeMatch, de 5 000 millisecondes. Le pare-feu Windows nécessite que le modèle de réponse multidiffusion/unidiffusion 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 port 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 à privilèges inférieurs par le biais d’une réservation d’URL dans HTTP.sys et sont également réservés à IANA.

Partage de port UDP

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

proxy CD1 WS-Discovery v1.1

WSDAPI recherche et communique avec un proxy de découverte qui implémente le protocole de mode managé CD1 WS-Discovery v1.1. WS-Discovery v1.1 CD1 est la première révision de WS-Discovery à 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 WS-Discovery Probe 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 sonde HTTP ou une demande de résolution au point de terminaison de proxy spécifié, tel que défini dans WS-Discovery v1.1 CD1.