Funcionalidade de WS-Discovery adicional

Em alguns casos, o Perfil de Dispositivos para Serviços Web (DPWS) e as especificações relacionadas não definem explicitamente a funcionalidade de implementação. Por exemplo, a especificação WS-Discovery não define o comportamento do cliente e do host em ambientes multilocatários. Quando o WSDAPI foi implementado, algumas funcionalidades de descoberta foram adicionadas além da funcionalidade definida na especificação.

O WSDAPI também implementa partes selecionadas de WS-Discovery CD1 v1.1 para se comunicar com um proxy de descoberta por HTTP.

A finalidade deste tópico é descrever a funcionalidade de descoberta implementada pelo WSDAPI, mas não descrita de outra forma nas especificações de WS-Discovery ou DPWS.

Endereços IPv6 e o formato de URI soap.udp

SOAP-over-UDP e WS-Discovery não descrevem explicitamente como um endereço IPv6 literal é representado no formato de URI soap.udp. RFC 2396, intitulado "Uniform Resource Identifiers (URI): Generic Syntax", indica que os endereços IPv6 literais não têm suporte no formato de URI soap.udp.

Para simplificar, o WSDAPI reconhece endereços IPv6 entre colchetes no esquema soap.udp. Por exemplo, o endereço soap.udp://[2001:abcd:0001:0002:0003:0004:0005:0032]:3702 é reconhecido pelo WSDAPI. Isso é semelhante a como os endereços IPv6 são tratados em HTTP.

Olá e XAddrs

O objeto de hospedagem DPWS do WSDAPI nunca enviará uma mensagem de WS-Discovery Hello com XAddrs no corpo da mensagem. Um cliente sempre enviará uma mensagem Resolver depois de receber uma mensagem Hello se o cliente precisar obter os XAddrs.

Há dois benefícios dessa abordagem. Primeiro, um dispositivo criado no WSDAPI nunca exporá XAddrs que divulgam os endereços IP de redes privadas. Em segundo lugar, um dispositivo criado no WSDAPI expõe apenas XAddrs acessíveis ao cliente, o que significa que os endereços IPv6 nunca são enviados para um cliente IPv4.

Quando uma mensagem Probe ou Resolve é recebida, apenas um XAddr é enviado em resposta. O XAddr enviado corresponde ao endereço local no qual a solicitação foi recebida. Se a solicitação foi recebida entre sub-redes por IPv6, o WSDAPI fornecerá um endereço IPv6 global na resposta.

Endereços preferenciais

Um dispositivo pode fornecer vários XAddrs em uma mensagem Hello, ProbeMatch ou ResolveMatch . Um serviço também pode estar disponível em vários pontos de extremidade com endereços de transporte diferentes. Nesses casos, o WSDAPI tentará se comunicar com o dispositivo no primeiro endereço utilizável encontrado. Um endereço poderá ser usado se for de um protocolo disponível, como IPv4 em um computador em que o IPv4 está instalado ou IPv6 em um computador em que o IPv6 está instalado. Além disso, se o endereço veio de um dispositivo ou serviço que não está na sub-rede local, ele só poderá ser usado se for IPv4, site IPv6 local ou link IPv6 local.

WSDL na troca de metadados

Dispositivos e serviços criados no WSDAPI não fornecem seu WSDL na troca de metadados, a menos que seja estendido pelo aplicativo para fornecer essas informações. Por padrão, a provisionamento WSDL não faz parte do modelo de programação.

APP_MAX_DELAY

O DPWS define APP_MAX_DELAY, o intervalo aleatório para atrasar entre o recebimento de uma investigação e o envio de um ProbeMatch, como 5.000 milissegundos. O Firewall do Windows exige que o modelo de resposta unicast/solicitação multicast para UDP só funcione dentro da janela de firewall de 4 segundos. Como resultado, o WSDAPI transmitirá respostas em 2.500 ms ou menos, em vez da janela de 5.000 ms descrita por APP_MAX_DELAY.

Reservas de porta IANA

O WSDAPI usa a porta TCP 5357 para tráfego HTTP e a porta TCP 5358 para tráfego HTTPS por padrão. Essas portas são reservadas para processos de privilégios inferiores por meio de uma reserva de URL em HTTP.sys e também são reservadas com o IANA.

Compartilhamento de porta UDP

O WSDAPI usa o compartilhamento de porta. As mensagens Unicast enviadas para a porta 3702 podem não ser tratadas corretamente por todos os aplicativos baseados em WSDAPI. Se um aplicativo se associar exclusivamente à porta 3702, ele poderá impedir que aplicativos baseados em WSDAPI usem essa porta corretamente.

WS-Discovery proxy CD1 v1.1

O WSDAPI procurará e se comunicará com um proxy de descoberta que implementa o WS-Discovery protocolo de modo gerenciado CD1 v1.1. WS-Discovery cd1.1 é a primeira revisão do WS-Discovery a incluir uma descrição explícita de um protocolo HTTP para comunicação entre um proxy e um cliente ou dispositivo.

Para limitar o número de versões simultâneas usadas em solicitações multicast, o WSDAPI envia uma solicitação de investigação de WS-Discovery no namespace 2005/04, mas pesquisa o tipo WS-Discovery v1.1 CD1 DiscoveryProxy. Se um proxy responder, o WSDAPI enviará uma solicitação HTTP Probe ou Resolve para o ponto de extremidade de proxy especificado, conforme definido em WS-Discovery v1.1 CD1.