Freigeben über


Zusätzliche WS-Discovery Funktionalität

In einigen Fällen definieren das Geräteprofil für Webdienste (DPWS) und zugehörige Spezifikationen keine explizite Implementierungsfunktionalität. Die WS-Discovery- Spezifikation definiert z. B. kein Client- und Hostverhalten in Multi-Homed-Umgebungen. Bei der Implementierung von WSDAPI wurden einige Ermittlungsfunktionen über die in der Spezifikation definierte Funktionalität hinaus hinzugefügt.

WSDAPI implementiert auch ausgewählte Teile von WS-Discovery v1.1 CD1 für die Kommunikation mit einem Discoveryproxy ü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 Literal-IPv6-Adresse im soap.udp-URI-Format dargestellt wird. RFC 2396mit dem Titel "Uniform Resource Identifiers (URI): Generic Syntax" gibt an, dass literale IPv6-Adressen vom Soap.udp-URI-Format nicht unterstützt werden.

Aus Gründen der Einfachheit erkennt WSDAPI IPv6-Adressen, die in eckige Klammern im soap.udp-Schema 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 Auflösen Nachricht, nachdem eine Hello-Nachricht empfangen wurde, wenn der Client die XAddrs abrufen muss.

Es gibt zwei Vorteile dieses Ansatzes. Zunächst wird ein auf WSDAPI basierendes Gerät nie XAddrs verfügbar machen, die die IP-Adressen privater Netzwerke offenlegen. Zweitens macht ein gerät, das auf WSDAPI basiert, 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 Probe oder Auflösen einer Nachricht empfangen wird, wird nur ein einzelner XAddr als Antwort gesendet. Der gesendete XAddr entspricht der lokalen Adresse, an der die Anforderung empfangen wurde. Wenn die Anforderung über IPv6 über IPv6 empfangen wurde, stellt WSDAPI eine globale IPv6-Adresse in der Antwort bereit.

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 auf der ersten verwendbaren Adresse zu kommunizieren, die gefunden wird. 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 im 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 Probe und dem Senden eines ProbeMatch-als 5.000 Millisekunden verzögert wird. Die Windows-Firewall erfordert, dass das Multicastanforderungs-/Unicast-Antwortmodell für UDP nur innerhalb des 4-Sekunden-Firewallfensters funktioniert. Daher überträgt WSDAPI Antworten in 2.500 ms oder weniger, anstelle des durch APP_MAX_DELAY beschriebenen Fensters von 5.000 ms.

IANA Hafenreservierungen

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

UDP-Portfreigabe

WSDAPI verwendet Portfreigabe. Unicast-Nachrichten, die an Port 3702 gesendet werden, werden möglicherweise nicht ordnungsgemäß von allen WSDAPI-basierten Anwendungen behandelt. Wenn eine Anwendung exklusiv an Port 3702 gebunden ist, kann sie verhindern, dass WSDAPI-basierte Anwendungen diesen Port ordnungsgemäß verwenden.

WS-Discovery v1.1 CD1-Proxy

WSDAPI sucht und kommuniziert mit einem Ermittlungsproxy, der das WS-Discovery v1.1 CD1 Managed Mode-Protokoll implementiert. WS-Discovery v1.1 CD1 ist die erste Revision von WS-Discovery, um eine explizite Beschreibung eines HTTP-Protokolls für die Kommunikation zwischen einem Proxy und einem Client oder Gerät einzuschließen.

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