Funzionalità aggiuntive WS-Discovery

In alcuni casi, il profilo dispositivi per i servizi Web (DPWS) e le specifiche correlate non definiscono in modo esplicito le funzionalità di implementazione. Ad esempio, la specifica WS-Discovery non definisce il comportamento client e host negli ambienti multi-homed. Quando WSDAPI è stato implementato, alcune funzionalità di individuazione sono state aggiunte oltre la funzionalità definita nella specifica.

WSDAPI implementa anche parti selezionate di WS-Discovery v1.1 CD1 per comunicare con un proxy di individuazione tramite HTTP.

Lo scopo di questo argomento è descrivere le funzionalità di individuazione implementate da WSDAPI ma non descritte in caso contrario nelle specifiche DPWS o WS-Discovery.

Indirizzi IPv6 e formato URI soap.udp

SOAP-over-UDP e WS-Discovery non descrivono in modo esplicito come un indirizzo IPv6 letterale è rappresentato nel formato URI soap.udp. RFC 2396, intitolato "Uniform Resource Identifiers (URI): sintassi generica", indica che gli indirizzi IPv6 letterali non sono supportati dal formato URI soap.udp.

Per semplicità, WSDAPI riconosce gli indirizzi IPv6 racchiusi tra parentesi quadre nello schema soap.udp. Ad esempio, l'indirizzo soap.udp://[2001:abcd:0001:0002:0003:0004:0005:0032]:3702 viene riconosciuto da WSDAPI. Questo è simile al modo in cui vengono gestiti gli indirizzi IPv6 in HTTP.

Hello and XAddrs

L'oggetto di hosting DPWS di WSDAPI non invierà mai un messaggio Hello WS-Discovery con XAddrs nel corpo del messaggio. Un client invia sempre un messaggio Resolve dopo aver ricevuto un messaggio Hello se il client deve ottenere XAddrs.

Esistono due vantaggi di questo approccio. Prima di tutto, un dispositivo basato su WSDAPI non espone mai XAddrs che rivela gli indirizzi IP delle reti private. In secondo luogo, un dispositivo basato su WSDAPI espone solo XAddrs accessibili al client, il che significa che gli indirizzi IPv6 non vengono mai inviati a un client IPv4.

Quando viene ricevuto un messaggio Probe o Resolve, viene inviato in risposta solo un singolo XAddr. XAddr inviato corrisponde all'indirizzo locale in cui è stata ricevuta la richiesta. Se la richiesta è stata ricevuta tra subnet su IPv6, WSDAPI fornirà un indirizzo IPv6 globale nella risposta.

Indirizzi preferiti

Un dispositivo può fornire più XAddrs in un messaggio Hello, ProbeMatch o ResolveMatch. Un servizio può essere disponibile anche in più endpoint con indirizzi di trasporto diversi. In questi casi, WSDAPI tenterà di comunicare con il dispositivo nel primo indirizzo utilizzabile trovato. Un indirizzo è utilizzabile se proviene da un protocollo disponibile, ad esempio IPv4 in un computer in cui è installato IPv4 o IPv6 in un computer in cui è installato IPv6. Inoltre, se l'indirizzo proviene da un dispositivo o da un servizio che non si trova nella subnet locale, è utilizzabile solo se è IPv4, sito IPv6 locale o collegamento IPv6 locale.

WSDL nello scambio di metadati

I dispositivi e i servizi basati su WSDAPI non forniscono il proprio WSDL nei metadati, a meno che non vengano estesi dall'applicazione per fornire queste informazioni. Per impostazione predefinita, il provisioning WSDL non fa parte del modello di programmazione.

APP_MAX_DELAY

DPWS definisce APP_MAX_DELAY, l'intervallo casuale per ritardare la ricezione di un probe e l'invio di probeMatch, come 5.000 millisecondi. Windows Firewall richiede che il modello di risposta multicast request/unicast per UDP funzioni solo all'interno della finestra del firewall 4. Di conseguenza, WSDAPI trasmetterà risposte in 2.500 ms o meno, anziché la finestra di 5.000 ms descritta da APP_MAX_DELAY.

Prenotazioni di porte IANA

WSDAPI usa la porta TCP 5357 per il traffico HTTP e la porta TCP 5358 per il traffico HTTPS per impostazione predefinita. Queste porte sono riservate ai processi con privilegi inferiori tramite una prenotazione URL in HTTP.sys e sono riservate anche con IANA.

Condivisione porta UDP

WSDAPI usa la condivisione delle porte. I messaggi unicast inviati alla porta 3702 potrebbero non essere gestiti correttamente da tutte le applicazioni basate su WSDAPI. Se un'applicazione si associa esclusivamente alla porta 3702, può impedire alle applicazioni basate su WSDAPI di usare correttamente tale porta.

proxy WS-Discovery v1.1 CD1

WSDAPI cercherà e comunicherà con un proxy di individuazione che implementa il protocollo in modalità gestita WS-Discovery v1.1 CD1. WS-Discovery v1.1 CD1 è la prima revisione di WS-Discovery per includere una descrizione esplicita di un protocollo HTTP per la comunicazione tra un proxy e un client o un dispositivo.

Per limitare il numero di versioni simultanee usate nelle richieste multicast, WSDAPI invia una richiesta di probe WS-Discovery nello spazio dei nomi 2005/04, ma cerca il tipo discoveryProxy WS-Discovery v1.1 CD1. Se un proxy risponde, WSDAPI invierà una richiesta HTTP Probe o Resolve all'endpoint proxy specificato, come definito in WS-Discovery v1.1 CD1.