Dodatkowe funkcje WS-Discovery

W niektórych przypadkach profil urządzeń dla usług sieci Web (DPWS) i powiązane specyfikacje nie definiują jawnie funkcji implementacji. Na przykład specyfikacja WS-Discovery nie definiuje zachowania klienta i hosta w środowiskach wieloawarowych. Po zaimplementowaniu interfejsu WSDAPI niektóre funkcje odnajdywania zostały dodane poza funkcjonalność zdefiniowaną w specyfikacji.

WSDAPI implementuje również wybrane części WS-Discovery 1.1 CD1 do komunikacji z serwerem proxy odnajdywania za pośrednictwem protokołu HTTP.

Celem tego tematu jest opisanie funkcji odnajdywania zaimplementowanych przez interfejs WSDAPI, ale nie opisano w inny sposób w specyfikacji programu DPWS lub WS-Discovery.

Adresy IPv6 i format identyfikatora URI protokołu soap.udp

Protokoły SOAP over-UDP i WS-Discovery nie opisują jawnie sposobu reprezentowania literału adresu IPv6 w formacie identyfikatora URI soap.udp. RFC 2396, zatytułowaną "Uniform Resource Identifiers (URI): Generic Syntax" (Identyfikatory URI): Składnia ogólna) wskazuje, że adresy IPv6 literału nie są obsługiwane przez format identyfikatora URI soap.udp.

Dla uproszczenia interfejs WSDAPI rozpoznaje adresy IPv6 ujęte w nawiasy kwadratowe w schemacie soap.udp. Na przykład adres soap.udp://[2001:abcd:0001:0002:0003:0004:0005:0032]:3702 jest rozpoznawany przez interfejs WSDAPI. Jest to podobne do sposobu obsługi adresów IPv6 w protokole HTTP.

Hello i XAddrs

Obiekt hostingu dpWS programu WSDAPI nigdy nie wyśle komunikatu WS-Discovery Hello z XAddrs w treści komunikatu. Klient zawsze wysyła komunikat Resolve po otrzymaniu komunikatu hello, jeśli klient musi pobrać XAddrs.

Istnieją dwie korzyści wynikające z tego podejścia. Po pierwsze urządzenie oparte na interfejsie WSDAPI nigdy nie uwidacznia XAddrs, które ujawniają adresy IP sieci prywatnych. Po drugie, urządzenie oparte na WSDAPI uwidacznia tylko XAddrs, które są dostępne dla klienta, co oznacza, że adresy IPv6 nigdy nie są wysyłane do klienta IPv4.

Po odebraniu sondy lub rozwiązaniu problemu zostanie wysłany tylko jeden element XAddr. Wysłany element XAddr odpowiada adresowi lokalnemu, na którym odebrano żądanie. Jeśli żądanie zostało odebrane w podsieciach za pośrednictwem protokołu IPv6, interfejs WSDAPI udostępni globalny adres IPv6 w odpowiedzi.

Preferowane adresy

Urządzenie może dostarczać wiele XAddrs w hello, ProbeMatchlub ResolveMatch komunikatu. Usługa może być również dostępna w wielu punktach końcowych z różnymi adresami transportu. W takich przypadkach interfejs WSDAPI spróbuje nawiązać komunikację z urządzeniem na pierwszym dostępnym adresie, który znajdzie. Adres jest używany, jeśli pochodzi z dostępnego protokołu, takiego jak IPv4 na maszynie, na której zainstalowano protokół IPv4 lub IPv6 na maszynie, na której zainstalowano protokół IPv6. Ponadto jeśli adres pochodzi z urządzenia lub usługi, która nie znajduje się w podsieci lokalnej, można jej używać tylko wtedy, gdy jest to adres IPv4, lokacja IPv6 lokalna lub połączenie IPv6 lokalne.

WSDL w zamianie metadanych

Urządzenia i usługi utworzone na podstawie interfejsu WSDAPI nie udostępniają ich WSDL w ramach wymiany metadanych, chyba że aplikacja rozszerzy tę informację. Domyślnie aprowizacja WSDL nie jest częścią modelu programowania.

APP_MAX_DELAY

Program DPWS definiuje APP_MAX_DELAY, losowy interwał opóźnienia między odbieraniem sondy i wysyłaniem ProbeMatch, jako 5000 milisekund. Zapora systemu Windows wymaga, aby model odpowiedzi żądania multiemisji/emisji pojedynczej dla protokołu UDP działał tylko w 4-sekundowym oknie zapory. W rezultacie interfejs WSDAPI będzie przesyłać odpowiedzi w ciągu 2500 ms lub mniej, zamiast okna 5000 ms opisanego przez APP_MAX_DELAY.

Rezerwacje portów IANA

WSDAPI domyślnie używa portu TCP 5357 dla ruchu HTTP i portu TCP 5358 dla ruchu HTTPS. Te porty są zarezerwowane dla procesów niższego poziomu uprawnień za pośrednictwem rezerwacji adresu URL w HTTP.sys, a także są zarezerwowane w usłudze IANA.

Udostępnianie portów UDP

WSDAPI używa udostępniania portów. Komunikaty emisji pojedynczej wysyłane do portu 3702 mogą nie być prawidłowo obsługiwane przez wszystkie aplikacje oparte na interfejsie WSDAPI. Jeśli aplikacja wiąże się wyłącznie z portem 3702, może to uniemożliwić aplikacjom opartym na protokole WSDAPI prawidłowe korzystanie z tego portu.

serwer proxy usługi WS-Discovery w wersji 1.1 CD1

WSDAPI wyszukuje i komunikuje się z serwerem proxy odnajdywania, który implementuje protokół trybu zarządzanego WS-Discovery 1.1 CD1. WS-Discovery 1.1 CD1 jest pierwszą poprawką WS-Discovery, aby dołączyć jawny opis protokołu HTTP do komunikacji między serwerem proxy a klientem lub urządzeniem.

Aby ograniczyć liczbę współbieżnych wersji używanych w żądaniach multiemisji, WSDAPI wysyła żądanie sondy WS-Discovery w przestrzeni nazw 2005/04, ale wyszukuje typ WS-Discovery v1.1 CD1 DiscoveryProxy. Jeśli serwer proxy odpowie, WSDAPI wyśle sondę HTTP lub rozwiąże żądanie do określonego punktu końcowego serwera proxy zgodnie z definicją w WS-Discovery v1.1 CD1.