Funcionalidade WS-Discovery Adicional

Em alguns casos, o Devices Profile for Web Services (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 multi-homed. 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 comunicação com um proxy de descoberta por HTTP.

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

Endereços IPv6 e o formato URI soap.udp

SOAP-over-UDP e WS-Discovery não descrevem explicitamente como um endereço IPv6 literal é representado no formato URI soap.udp. RFC 2396, intitulado "Uniform Resource Identifiers (URI): Generic Syntax", indica que endereços IPv6 literais não são suportados pelo formato 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 à forma como os endereços IPv6 são tratados em HTTP.

Olá e XAddrs

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

Esta abordagem apresenta duas vantagens. Primeiro, um dispositivo construído em WSDAPI nunca irá expor XAddrs que divulgam os endereços IP de redes privadas. Em segundo lugar, um dispositivo construído em WSDAPI só expõe XAddrs que são 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 único 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 em sub-redes via IPv6, o WSDAPI fornecerá um endereço IPv6 global na resposta.

Endereços preferidos

Um dispositivo pode fornecer vários XAddrs em uma mensagem Hello, ProbeMatchou ResolveMatch. Um serviço também pode estar disponível em vários pontos finais com diferentes endereços de transporte. Nesses casos, o WSDAPI tentará se comunicar com o dispositivo no primeiro endereço utilizável encontrado. Um endereço é utilizável se for de um protocolo disponível, como IPv4 em uma máquina onde o IPv4 está instalado ou IPv6 em uma máquina onde 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ó é utilizável se for IPv4, IPv6 site local ou IPv6 link local.

WSDL no intercâmbio de metadados

Os dispositivos e serviços criados no WSDAPI não fornecem seu WSDL na troca de metadados, a menos que sejam estendidos pelo aplicativo para fornecer essas informações. Por padrão, a provisão 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 um Probe e o envio de um ProbeMatch, como 5.000 milissegundos. O Firewall do Windows requer que o modelo de resposta de solicitação/unicast multicast para UDP só funcione na 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 portuárias 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 mais baixos por meio de uma reserva de URL no HTTP.syse também são reservadas com a IANA.

Compartilhamento de porta UDP

O WSDAPI usa o compartilhamento de portas. 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 liga exclusivamente à porta 3702, ele pode impedir que aplicativos baseados em WSDPI usem essa porta corretamente.

WS-Discovery v1.1 Proxy CD1

O WSDAPI procurará e se comunicará com um proxy de descoberta que implementa o protocolo de modo gerenciado CD1 WS-Discovery v1.1. WS-Discovery CD1 v1.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 de multicast, o WSDAPI envia uma solicitação WS-Discovery Probe no namespace 2005/04, mas procura o tipo DiscoveryProxy CD1 WS-Discovery v1.1. Se um proxy responder, o WSDAPI enviará uma solicitação HTTP Probe ou Resolve para o ponto de extremidade de proxy especificado, conforme definido no CD1 WS-Discovery v1.1.