Modelo de resolución de nombres
Un espacio de nombres hace referencia a alguna capacidad para asociar (como mínimo) el protocolo y los atributos de direccionamiento de un servicio de red con uno o varios nombres descriptivos. Muchos espacios de nombres están actualmente en uso amplio, incluido el Sistema de nombres de dominio (DNS) de Internet, Servicios de dominio de Active Directory, la enlazadora, netWare Directory Services (NDS) de Novell y X.500. Estos espacios de nombres varían ampliamente en cómo se organizan e implementan. Algunas de sus propiedades son especialmente importantes para comprender desde la perspectiva de la resolución de nombres winsock.
Tipos de espacios de nombres
Hay tres tipos diferentes de espacios de nombres en los que se puede registrar un servicio:
- Dinámica
- estática
- Persistente
Los espacios de nombres dinámicos permiten que los servicios se registren con el espacio de nombres sobre la marcha y que los clientes detecten los servicios disponibles en tiempo de ejecución. Los espacios de nombres dinámicos se basan con frecuencia en las difusiones para indicar la disponibilidad continua de un servicio de red. Entre los ejemplos más antiguos de espacios de nombres dinámicos se incluyen el espacio de nombres del Protocolo de publicidad de servicios (SAP) que se usa en un entorno de NetWare y el espacio de nombres del Protocolo de enlace de nombres (NBP) usado por AppleTalk. El espacio de nombres del Protocolo de resolución de nombres del mismo nivel (PNRP) usado en Windows es un ejemplo más reciente de un espacio de nombres dinámico.
Los espacios de nombres estáticos requieren que todos los servicios se registren con antelación, es decir, cuando se crea el espacio de nombres. Un ejemplo de un espacio de nombres estático son los hosts, protocolos y archivos de servicios usados por la mayoría de las implementaciones de TCP/IP. En Windows, estos archivos normalmente se encuentran en la carpeta C:\windows\system32\drivers\etc .
Los espacios de nombres persistentes permiten a los servicios registrarse con el espacio de nombres sobre la marcha. Sin embargo, a diferencia de los espacios de nombres dinámicos, los espacios de nombres persistentes conservan la información de registro en el almacenamiento no volátil, donde permanece hasta ese momento, como las solicitudes de servicio que se quitarán. Los espacios de nombres persistentes se escriben por servicios de directorio como X.500 y NDS (servicio de directorio de NetWare). Estos entornos permiten agregar, eliminar y modificar las propiedades del servicio. Además, el objeto de servicio que representa el servicio dentro del servicio de directorio podría tener una variedad de atributos asociados al servicio. El atributo más importante para las aplicaciones cliente es la información de direccionamiento del servicio. DNS es otro ejemplo de un espacio de nombres persistente. Aunque hay una manera programática de resolver nombres DNS mediante Windows Sockets, el proveedor de espacios de nombres DNS en Windows no admite el registro de nuevos nombres DNS mediante Winsock. Debe usar las funciones DNS directamente para registrar nombres DNS. Para más información, consulte la referencia de DNS.
Organización del espacio de nombres
Muchos espacios de nombres se organizan jerárquicamente. Algunos, como X.500 y NDS, permiten un anidamiento ilimitado. Otros permiten combinar los servicios en un único nivel de jerarquía o grupo. Normalmente, esto se conoce como grupo de trabajo. Al construir una consulta, a menudo es necesario establecer un punto de contexto dentro de una jerarquía de espacios de nombres desde la que se iniciará la búsqueda.
Arquitectura del proveedor de espacios de nombres
Naturalmente, las interfaces mediante programación que se usan para consultar los distintos tipos de espacios de nombres y para registrar información dentro de un espacio de nombres (si se admite) difieren ampliamente. Un proveedor de espacios de nombres es una parte de software residente localmente que sabe cómo asignar entre el SPI del espacio de nombres Winsock y algún espacio de nombres existente (que se puede implementar localmente o acceder a él a través de la red). La arquitectura del proveedor de espacios de nombres se muestra de la siguiente manera:
Tenga en cuenta que 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 servicio hace referencia a la mitad del servidor de una aplicación cliente/servidor. En Winsock, 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. Entre los ejemplos de clases de servicio se incluyen servidor FTP, 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. En el caso de 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 (en orden de bytes de host) 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.
La noción de una clase de servicio existe para permitir que se establezca un conjunto de atributos que se mantienen en común por todas las instancias de un servicio determinado. Este conjunto de atributos se proporciona en el momento en que la clase de servicio se define en Winsock y se conoce como información de esquema de clase de servicio. Cuando se instala y se pone a disposición de un servicio en un equipo host, se considera creado una instancia del servicio y su nombre de servicio se usa para distinguir una instancia determinada del servicio de otras instancias que pueden conocerse en 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. Siempre que sea posible, el Ws2_32.dll proporciona 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 suministrar 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 necesitan esta información deben tener un mecanismo de reserva para obtenerlo a través de medios específicos del espacio de nombres.
Como se indicó anteriormente, Internet ha adoptado lo que se puede denominar modelo de servicio centrado en host. Las aplicaciones que necesitan localizar la dirección de transporte de un servicio generalmente deben resolver primero la dirección de un host específico conocido para hospedar el servicio. A esta dirección, agregan el número de puerto conocido y, por tanto, crean una dirección de transporte completa. Para facilitar la resolución de nombres de host, se ha asignado previamente un identificador de clase de servicio especial (SVCID_HOSTNAME). Una consulta que especifica SVCID_HOSTNAME como clase de servicio y especifica un nombre de host para el nombre de instancia del servicio devolverá información de dirección de host si la consulta se realiza correctamente.
En Windows Sockets 2, las aplicaciones independientes del protocolo deben evitar la necesidad de comprender los detalles internos de una dirección de transporte. Por lo tanto, la necesidad de obtener primero una dirección de host y, a continuación, agregar en el puerto es problemática. Para evitarlo, las consultas también pueden incluir el nombre conocido de un servicio determinado y el protocolo sobre el que opera el servicio, como FTP a través de TCP. En este caso, una consulta correcta devuelve una dirección de transporte completa para el servicio especificado en el host indicado y la aplicación no es necesaria para inspeccionar los elementos internos de una estructura sockaddr .
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 para Winsock solo pueden acomodar 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 con el puerto expresado en orden de bytes de host. Por lo tanto, todos los servicios conocidos, como HTTP, FTP, Telnet, Whois, etc. son bien compatibles.
Siguiendo con nuestro ejemplo de clase de servicio, los nombres de instancia del servicio FTP pueden ser "alder.intel.com" o "ftp.microsoft.com" mientras que una instancia del 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 del 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.
Temas relacionados