Funcionalidad adicional de WS-Discovery

En algunos casos, el perfil de dispositivos para servicios web (DPWS) y las especificaciones relacionadas no definen explícitamente la funcionalidad de implementación. Por ejemplo, la especificación WS-Discovery no define el comportamiento de cliente y host en entornos multi-homed. Cuando se implementó WSDAPI, se agregó alguna funcionalidad de detección más allá de la funcionalidad definida en la especificación.

WSDAPI también implementa partes seleccionadas de WS-Discovery CD1.1 v1 para comunicarse con un proxy de detección a través de HTTP.

El propósito de este tema es describir la funcionalidad de detección implementada por WSDAPI, pero no se describe en las especificaciones de DPWS o WS-Discovery.

Direcciones IPv6 y el formato de URI soap.udp

SOAP sobre UDP y WS-Discovery no describen explícitamente cómo se representa una dirección IPv6 literal en el formato URI soap.udp. RFC 2396, titulado "Identificadores uniformes de recursos (URI): sintaxis genérica", indica que las direcciones IPv6 literales no son compatibles con el formato URI soap.udp.

Para simplificar, WSDAPI reconoce las direcciones IPv6 entre corchetes del esquema soap.udp. Por ejemplo, WSDAPI reconoce la dirección soap.udp://[2001:abcd:0001:0002:0003:0004:0005:0032]:3702 . Esto es similar a cómo se controlan las direcciones IPv6 en HTTP.

Hello y XAddrs

El objeto de hospedaje DPWS de WSDAPI nunca enviará un mensaje hello WS-Discovery con XAddrs en el cuerpo del mensaje. Un cliente siempre enviará un mensaje Resolve después de recibir un mensaje Hello si el cliente necesita obtener los XAddrs.

Hay dos ventajas de este enfoque. En primer lugar, un dispositivo basado en WSDAPI nunca expondrá XAddrs que revelen las direcciones IP de las redes privadas. En segundo lugar, un dispositivo basado en WSDAPI solo expone XAddrs que son accesibles para el cliente, lo que significa que las direcciones IPv6 nunca se envían a un cliente IPv4.

Cuando se recibe un mensaje de sondeo o resolución, solo se envía un XAddr único en respuesta. El XAddr enviado corresponde a la dirección local en la que se recibió la solicitud. Si la solicitud se recibió entre subredes a través de IPv6, WSDAPI proporcionará una dirección IPv6 global en la respuesta.

Direcciones preferidas

Un dispositivo puede proporcionar varios XAddrs en un mensaje Hello, ProbeMatch o ResolveMatch . Un servicio también puede estar disponible en varios puntos de conexión con diferentes direcciones de transporte. En estos casos, WSDAPI intentará comunicarse con el dispositivo en la primera dirección utilizable que encuentre. Una dirección se puede usar si procede de un protocolo disponible, como IPv4 en un equipo donde se instala IPv4 o IPv6 en un equipo donde está instalado IPv6. Además, si la dirección procede de un dispositivo o servicio que no está en la subred local, solo se puede usar si es IPv4, local del sitio IPv6 o IPv6 local.

WSDL en el intercambio de metadatos

Los dispositivos y servicios basados en WSDAPI no proporcionan su WSDL en el intercambio de metadatos a menos que la aplicación lo extienda para proporcionar esta información. De forma predeterminada, el aprovisionamiento de WSDL no forma parte del modelo de programación.

APP_MAX_DELAY

DPWS define APP_MAX_DELAY, el intervalo aleatorio que se retrasará entre recibir un sondeo y enviar un ProbeMatch, como 5000 milisegundos. Firewall de Windows requiere que el modelo de respuesta de solicitud o unidifusión de multidifusión para UDP solo funcione dentro de la ventana de firewall de 4 segundos. Como resultado, WSDAPI transmitirá respuestas en 2500 ms o menos, en lugar de la ventana de 5000 ms descrita por APP_MAX_DELAY.

Reservas de puertos de IANA

WSDAPI usa el puerto TCP 5357 para el tráfico HTTP y el puerto TCP 5358 para el tráfico HTTPS de forma predeterminada. Estos puertos están reservados para procesos con privilegios inferiores a través de una reserva de direcciones URL en HTTP.sys, y también se reservan con IANA.

Uso compartido de puertos UDP

WSDAPI usa el uso compartido de puertos. Es posible que todas las aplicaciones basadas en WSDAPI no controlen correctamente los mensajes de unidifusión enviados al puerto 3702. Si una aplicación se enlaza exclusivamente al puerto 3702, puede impedir que las aplicaciones basadas en WSDAPI usen ese puerto correctamente.

proxy de CD1 de WS-Discovery v1.1

WSDAPI buscará y comunicará con un proxy de detección que implemente el protocolo de modo administrado cd1 de WS-Discovery v1.1. WS-Discovery CD1.1 es la primera revisión de WS-Discovery para incluir una descripción explícita de un protocolo HTTP para la comunicación entre un proxy y un cliente o dispositivo.

Para limitar el número de versiones simultáneas usadas en las solicitudes de multidifusión, WSDAPI envía una solicitud de sondeo de WS-Discovery en el espacio de nombres 2005/04, pero busca el tipo discoveryProxy de WS-Discovery v1.1. Si un proxy responde, WSDAPI enviará una solicitud de sondeo HTTP o Resolución al punto de conexión de proxy especificado tal y como se define en WS-Discovery CD1.1.