Zusätzliche WS-Discovery Funktionalität

In einigen Fällen definieren das Geräteprofil für Webdienste (DPWS) und die zugehörigen Spezifikationen die Implementierungsfunktionalität nicht explizit. Beispielsweise definiert die WS-Discovery-Spezifikation nicht das Client- und Hostverhalten in Umgebungen mit mehreren Homed-Umgebungen. Bei der Implementierung von WSDAPI wurden einige Ermittlungsfunktionen hinzugefügt, die über die in der Spezifikation definierten Funktionen hinausgehen.

WSDAPI implementiert auch ausgewählte Teile von WS-Discovery v1.1 CD1 für die Kommunikation mit einem Ermittlungsproxy über HTTP.

Der Zweck dieses Themas besteht darin, die von WSDAPI implementierte Ermittlungsfunktionalität zu beschreiben, aber nicht anderweitig in den DPWS- oder WS-Discovery-Spezifikationen beschrieben.

IPv6-Adressen und das soap.udp-URI-Format

SOAP-over-UDP und WS-Discovery beschreiben nicht explizit, wie eine literale IPv6-Adresse im soap.udp-URI-Format dargestellt wird. RFC 2396 mit dem Titel "Uniform Resource Identifiers (URI): Generic Syntax" gibt an, dass literale IPv6-Adressen vom soap.udp-URI-Format nicht unterstützt werden.

Der Einfachheit halber erkennt WSDAPI IPv6-Adressen, die im soap.udp-Schema in eckigen Klammern eingeschlossen sind. Beispielsweise wird die Adresse soap.udp://[2001:abcd:0001:0002:0003:0004:0005:0032]:3702 von WSDAPI erkannt. Dies ähnelt der Behandlung von IPv6-Adressen in HTTP.

Hello und XAddrs

Das DPWS-Hostingobjekt von WSDAPI sendet niemals eine WS-Discovery Hello-Nachricht mit XAddrs im Nachrichtentext. Ein Client sendet immer eine Resolve-Nachricht , nachdem eine Hello-Nachricht empfangen wurde, wenn der Client die XAddrs abrufen muss.

Dieser Ansatz bietet zwei Vorteile. Erstens macht ein gerät, das auf WSDAPI basiert, niemals XAddrs verfügbar, die die IP-Adressen privater Netzwerke offenlegen. Zweitens macht ein auf WSDAPI basierendes Gerät nur XAddrs verfügbar, die für den Client zugänglich sind, was bedeutet, dass IPv6-Adressen nie an einen IPv4-Client gesendet werden.

Wenn eine Test - oder Resolve-Nachricht empfangen wird, wird nur eine einzelne XAddr-Antwort gesendet. Das gesendete XAddr entspricht der lokalen Adresse, an der die Anforderung empfangen wurde. Wenn die Anforderung subnetzübergreifend über IPv6 empfangen wurde, gibt WSDAPI in der Antwort eine globale IPv6-Adresse an.

Bevorzugte Adressen

Ein Gerät kann mehrere XAddrs in einer Hello-, ProbeMatch- oder ResolveMatch-Nachricht bereitstellen. Ein Dienst kann auch an mehreren Endpunkten mit unterschiedlichen Transportadressen verfügbar sein. In diesen Fällen versucht WSDAPI, mit dem Gerät über die erste verwendbare Adresse zu kommunizieren, die es findet. Eine Adresse kann verwendet werden, wenn sie aus einem verfügbaren Protokoll stammt, z. B. IPv4 auf einem Computer, auf dem IPv4 installiert ist, oder IPv6 auf einem Computer, auf dem IPv6 installiert ist. Wenn die Adresse von einem Gerät oder Dienst stammt, das sich nicht im lokalen Subnetz befindet, kann sie nur verwendet werden, wenn es sich um einen lokalen IPv4-, IPv6-Standort oder einen lokalen IPv6-Link handelt.

WSDL beim Metadatenaustausch

Geräte und Dienste, die auf WSDAPI basieren, stellen ihre WSDL nicht im Metadatenaustausch bereit, es sei denn, die Anwendung erweitert, um diese Informationen bereitzustellen. Standardmäßig ist die WSDL-Bereitstellung nicht Teil des Programmiermodells.

APP_MAX_DELAY

DPWS definiert APP_MAX_DELAY, das zufällige Intervall, das zwischen dem Empfangen eines Tests und dem Senden eines ProbeMatch verzögert werden soll, als 5.000 Millisekunden. Die Windows-Firewall erfordert, dass das Multicastanforderungs-/Unicastantwortmodell für UDP nur innerhalb des 4-Sekunden-Firewallfensters funktioniert. Daher überträgt WSDAPI Antworten in maximal 2.500 ms anstelle des von APP_MAX_DELAY beschriebenen 5.000 ms-Fensters.

IANA-Hafenreservierungen

WSDAPI verwendet standardmäßig TCP-Port 5357 für HTTP-Datenverkehr und TCP-Port 5358 für HTTPS-Datenverkehr. Diese Ports sind für Prozesse mit niedrigeren Berechtigungen über eine URL-Reservierung in HTTP.sys reserviert und auch für IANA reserviert.

UDP-Portfreigabe

WSDAPI verwendet die Portfreigabe. Unicastnachrichten, die an Port 3702 gesendet werden, werden möglicherweise nicht von allen WSDAPI-basierten Anwendungen ordnungsgemäß verarbeitet. Wenn eine Anwendung ausschließlich an Port 3702 gebunden ist, kann dies WSDAPI-basierte Anwendungen daran hindern, diesen Port ordnungsgemäß zu verwenden.

WS-Discovery v1.1 CD1-Proxy

WSDAPI sucht nach einem Ermittlungsproxy und kommuniziert mit diesem, der das protokoll WS-Discovery v1.1 CD1 im verwalteten Modus implementiert. WS-Discovery v1.1 CD1 ist die erste Revision von WS-Discovery, die eine explizite Beschreibung eines HTTP-Protokolls für die Kommunikation zwischen einem Proxy und einem Client oder Gerät enthält.

Um die Anzahl gleichzeitiger Versionen zu begrenzen, die in Multicastanforderungen verwendet werden, sendet WSDAPI eine WS-Discovery Testanforderung im Namespace 2005/04, sucht jedoch nach dem WS-Discovery v1.1 CD1 DiscoveryProxy-Typ. Wenn ein Proxy antwortet, sendet WSDAPI einen HTTP-Test oder eine Resolve-Anforderung an den angegebenen Proxyendpunkt, wie in WS-Discovery v1.1 CD1 definiert.