Modelo de Resolução de Nomes
Um namespace refere-se a algum recurso para associar (no mínimo) o protocolo e os atributos de endereçamento de um serviço de rede com um ou mais nomes amigáveis. Muitos namespaces estão atualmente em uso amplo, incluindo o DNS (Sistema de Nomes de Domínio) da Internet, Active Directory Domain Services, a associação, o NetWare Directory Services (NDS) da Novell e X.500. Esses namespaces variam amplamente na forma como são organizados e implementados. Algumas de suas propriedades são particularmente importantes para entender da perspectiva da resolução de nomes winsock.
Tipos de namespaces
Há três tipos diferentes de namespaces nos quais um serviço pode ser registrado:
- Dinâmico
- Estático
- Persistente
Namespaces dinâmicos permitem que os serviços se registrem no namespace em tempo real e que os clientes descubram os serviços disponíveis em tempo de execução. Namespaces dinâmicos frequentemente dependem de transmissões para indicar a disponibilidade contínua de um serviço de rede. Exemplos mais antigos de namespaces dinâmicos incluem o namespace sap (Service Advertising Protocol) usado em um ambiente NetWare e o namespace NBP (Name Binding Protocol) usado pelo AppleTalk. O namespace PNRP (Peer Name Resolution Protocol) usado no Windows é um exemplo mais recente de um namespace dinâmico.
Namespaces estáticos exigem que todos os serviços sejam registrados antecipadamente, ou seja, quando o namespace é criado. Um exemplo de namespace estático são os arquivos de hosts, protocolos e serviços usados pela maioria das implementações de TCP/IP. No Windows, esses arquivos normalmente estão localizados na pasta C:\windows\system32\drivers\etc .
Namespaces persistentes permitem que os serviços se registrem com o namespace em tempo real. No entanto, ao contrário dos namespaces dinâmicos, os namespaces persistentes mantêm as informações de registro no armazenamento não persistente onde elas permanecem até o momento em que o serviço solicita que ela seja removida. Namespaces persistentes são tipificados por serviços de diretório, como X.500 e NDS (Serviço de Diretório NetWare). Esses ambientes permitem a adição, exclusão e modificação de propriedades de serviço. Além disso, o objeto de serviço que representa o serviço dentro do serviço de diretório pode ter uma variedade de atributos associados ao serviço. O atributo mais importante para aplicativos cliente são as informações de endereçamento do serviço. DNS é outro exemplo de um namespace persistente. Embora haja uma maneira programática de resolve nomes DNS usando o Windows Sockets, o provedor de namespace DNS no Windows não dá suporte ao registro de novos nomes DNS usando Winsock. Você deve usar as funções DNS diretamente para registrar nomes DNS. Para obter mais informações, consulte a Referência de DNS.
Organização do namespace
Muitos namespaces são organizados hierarquicamente. Alguns, como X.500 e NDS, permitem aninhamento ilimitado. Outros permitem que os serviços sejam combinados em um único nível de hierarquia ou grupo. Normalmente, isso é conhecido como um grupo de trabalho. Ao construir uma consulta, geralmente é necessário estabelecer um ponto de contexto dentro de uma hierarquia de namespace da qual a pesquisa será iniciada.
Arquitetura do provedor de namespace
Naturalmente, as interfaces programáticas usadas para consultar os vários tipos de namespaces e registrar informações em um namespace (se houver suporte) diferem amplamente. Um provedor de namespace é um software localmente residente que sabe como mapear entre a SPI do namespace Winsock e algum namespace existente (que pode ser implementado localmente ou ser acessado por meio da rede). A arquitetura do provedor de namespace é ilustrada da seguinte maneira:
Observe que é possível que um determinado namespace, por exemplo, DNS, tenha mais de um provedor de namespace instalado em um determinado computador.
Conforme mencionado acima, o serviço de termo genérico refere-se à metade do servidor de um aplicativo cliente/servidor. No Winsock, um serviço é associado a uma classe de serviço e cada instância de um determinado serviço tem um nome de serviço que deve ser exclusivo dentro da classe de serviço. Exemplos de classes de serviço incluem SERVIDOR FTP, SQL Server, XYZ Corp. Servidor de Informações do Funcionário etc. Como o exemplo tenta ilustrar, algumas classes de serviço são bem conhecidas, enquanto outras são exclusivas e específicas para um aplicativo vertical específico. Em ambos os casos, cada classe de serviço é representada por um nome de classe e um identificador de classe. O nome da classe não precisa necessariamente ser exclusivo, mas o identificador de classe deve ser. Os GUIDs (Identificadores Globalmente Exclusivos) são usados para representar identificadores de classe de serviço. Para serviços conhecidos, os guids (nomes de classe e identificadores de classe) foram pré-alocados e as macros estão disponíveis para converter entre, por exemplo, números de porta TCP (em ordem de byte de host) e os GUIDs de identificador de classe correspondentes. Para outros serviços, o desenvolvedor escolhe o nome da classe e usa o utilitário Uuidgen.exe para gerar um GUID para o identificador de classe.
A noção de uma classe de serviço existe para permitir que um conjunto de atributos seja estabelecido que são mantidos em comum por todas as instâncias de um determinado serviço. Esse conjunto de atributos é fornecido no momento em que a classe de serviço é definida como Winsock e é conhecida como as informações de esquema da classe de serviço. Quando um serviço é instalado e disponibilizado em um computador host, esse serviço é considerado instanciado e seu nome de serviço é usado para distinguir uma instância específica do serviço de outras instâncias que podem ser conhecidas pelo namespace.
Observe que a instalação de uma classe de serviço só precisa ocorrer em computadores em que o serviço é executado, não em todos os clientes que podem utilizar o serviço. Sempre que possível, o Ws2_32.dll fornece informações de esquema de classe de serviço a um provedor de namespace no momento em que uma instanciação de um serviço deve ser registrada ou uma consulta de serviço é iniciada. O Ws2_32.dll, é claro, não armazena essas informações em si, mas tenta recuperá-la de um provedor de namespace que indicou sua capacidade de fornecer esses dados. Como não há nenhuma garantia de que o Ws2_32.dll possa fornecer o esquema de classe de serviço, os provedores de namespace que precisam dessas informações devem ter um mecanismo de fallback para obtê-lo por meio de meios específicos do namespace.
Conforme observado acima, a Internet adotou o que pode ser chamado de modelo de serviço centrado em host. Os aplicativos que precisam localizar o endereço de transporte de um serviço geralmente devem primeiro resolve o endereço de um host específico conhecido por hospedar o serviço. Para esse endereço, eles adicionam o número de porta conhecido e, portanto, criam um endereço de transporte completo. Para facilitar a resolução de nomes de host, um identificador de classe de serviço especial foi pré-alocado (SVCID_HOSTNAME). Uma consulta que especifica SVCID_HOSTNAME como a classe de serviço e especifica um nome de host para o nome da instância de serviço retornará informações de endereço do host se a consulta for bem-sucedida.
No Windows Sockets 2, os aplicativos que são independentes de protocolo devem evitar a necessidade de compreender os detalhes internos de um endereço de transporte. Portanto, a necessidade de primeiro obter um endereço de host e, em seguida, adicionar na porta é problemática. Para evitar isso, as consultas também podem incluir o nome conhecido de um determinado serviço e o protocolo sobre o qual o serviço opera, como FTP sobre TCP. Nesse caso, uma consulta bem-sucedida retorna um endereço de transporte completo para o serviço especificado no host indicado e o aplicativo não é necessário para inspecionar os internos de uma estrutura sockaddr .
O Sistema de Nomes de Domínio da Internet não tem um meio bem definido para armazenar informações de esquema de classe de serviço. Como resultado, os provedores de namespace DNS para Winsock só podem acomodar serviços TCP/IP conhecidos para os quais um GUID de classe de serviço foi pré-alocado.
Na prática, essa não é uma limitação grave, pois os GUIDs da classe de serviço foram pré-alocados para todo o conjunto de portas TCP e UDP, e as macros estão disponíveis para recuperar o GUID associado a qualquer porta TCP ou UDP com a porta expressa em ordem de byte de host. Assim, todos os serviços familiares, como HTTP, FTP, Telnet, Whois, etc. são bem compatíveis.
Continuando com nosso exemplo de classe de serviço, os nomes de instância do serviço FTP podem ser "alder.intel.com" ou "ftp.microsoft.com", enquanto uma instância da XYZ Corp. O Servidor de Informações do Funcionário pode ser chamado de "XYZ Corp. Employee Info Server Versão 3.5".
Nos dois primeiros casos, a combinação do GUID da classe de serviço para FTP e o nome do computador (fornecido como o nome da instância de serviço) identificam exclusivamente o serviço desejado. No terceiro caso, o nome do host em que o serviço reside pode ser descoberto no momento da consulta de serviço, portanto, o nome da instância de serviço não precisa incluir um nome de host.
Tópicos relacionados