Arquitectura del proveedor de espacios de nombres en el SPI

Las interfaces mediante programación usadas para consultar los distintos tipos de espacios de nombres y registrar información dentro de un espacio de nombres, si se admiten, difieren ampliamente. Un proveedor de espacios de nombres es una aplicación residente localmente que puede asignarse entre el SPI del espacio de nombres de Windows Sockets y algún espacio de nombres existente que se podría implementar localmente o acceder a él a través de la red. Esto se ilustra de la siguiente manera:

diagrama del proveedor del espacio de nombres

Nota

Es posible que un espacio de nombres determinado, por ejemplo, DNS, tenga instalado más de un proveedor de espacios de nombres en un equipo determinado.

 

Como se mencionó anteriormente, el término genérico, service, hace referencia a la mitad del servidor de una aplicación cliente/servidor. En Windows Sockets, un servicio está asociado a una clase de servicio y cada instancia de un servicio determinado tiene un nombre de servicio que debe ser único dentro de la clase de servicio. Algunos ejemplos de clases de servicio son FTP Server, SQL Server, XYZ Corp. Employee Info Server, etc.

Como se intenta ilustrar en el ejemplo, algunas clases de servicio son conocidas, mientras que otras son únicas y específicas de una aplicación vertical determinada. En cualquier caso, cada clase de servicio se representa mediante un nombre de clase y un identificador de clase. El nombre de clase no necesita ser necesariamente único, pero el identificador de clase debe ser. Los identificadores únicos globales (GUID) se usan para representar identificadores de clase de servicio. Para los servicios conocidos, los nombres de clase y los identificadores de clase (GUID) se han asignado previamente, y las macros están disponibles para convertir entre, por ejemplo, números de puerto TCP y los GUID de identificador de clase correspondientes. Para otros servicios, el desarrollador elige el nombre de clase y usa la utilidad Uuidgen.exe para generar un GUID para el identificador de clase.

El concepto de una clase de servicio existe para permitir que se establezca un conjunto de atributos que se mantienen en común en todas las instancias de un servicio determinado. Este conjunto de atributos se proporciona a Windows Sockets en el momento en que se define la clase de servicio y se conoce como información de esquema de clase de servicio. A su vez, el Ws2_32.dll retransmite esta información a todos los proveedores de espacios de nombres activos. Cuando se instala una instancia de un servicio y se pone a disposición en un equipo host, su nombre de servicio se usa para distinguir esta instancia concreta de otras que pueden ser conocidas por el espacio de nombres.

Tenga en cuenta que la instalación de una clase de servicio solo debe producirse en equipos donde se ejecuta el servicio, no en todos los clientes que pueden utilizar el servicio. Cuando sea posible, el Ws2_32.dll proporcionará información de esquema de clase de servicio a un proveedor de espacios de nombres en el momento en que se va a registrar una instancia de un servicio o se inicia una consulta de servicio. Por supuesto, el Ws2_32.dll no almacena esta información, sino que intenta recuperarla de un proveedor de espacios de nombres que haya indicado su capacidad de proporcionar estos datos. Dado que no hay ninguna garantía de que el Ws2_32.dll pueda proporcionar el esquema de clase de servicio, los proveedores de espacios de nombres que requieren esta información deben tener un mecanismo de reserva para obtenerlo a través de medios específicos del espacio de nombres.

El sistema de nombres de dominio de Internet no tiene un medio bien definido para almacenar información de esquema de clase de servicio. Como resultado, los proveedores de espacios de nombres DNS solo podrán dar cabida a servicios TCP/IP conocidos para los que se ha asignado previamente un GUID de clase de servicio. En la práctica, esto no es una limitación grave, ya que los GUID de clase de servicio se han asignado previamente para todo el conjunto de puertos TCP y UDP, y las macros están disponibles para recuperar el GUID asociado a cualquier puerto TCP o UDP. Por lo tanto, todos los servicios conocidos como ftp, telnet, whois, etc. son bien compatibles. Al consultar estos servicios, por convención, el nombre de host del equipo de destino es el nombre de la instancia de servicio.

Siguiendo con nuestro ejemplo de clase de servicio, los nombres de instancia del servicio ftp pueden ser "alder.intel.com" o "rhino.microsoft.com" mientras que una instancia de XYZ Corp. Employee Info Server podría denominarse "XYZ Corp. Employee Info Server versión 3.5". En los dos primeros casos, la combinación del GUID de clase de servicio para ftp y el nombre de equipo (proporcionado como nombre de instancia de servicio) identifican de forma única el servicio deseado. En el tercer caso, el nombre de host donde reside el servicio se puede detectar en el momento de la consulta del servicio, por lo que el nombre de la instancia de servicio no necesita incluir un nombre de host.