WINS proporciona una base de datos distribuida para registrar y buscar asociaciones de nombres de equipo y direcciones IP de forma dinámica en entornos de red enrutados. Este sistema resuelve el problema que se genera al resolver nombres en entornos complejos de redes interconectadas.
WINS reduce el uso de las transmisiones broadcast locales para resolver nombres y permite a los usuarios localizar los sistemas con facilidad en redes remotas. Además, cuando DHCP genera nuevas direcciones IP para equipos que cambian de una subred a otra, los cambios se actualizan automáticamente en la base de datos WINS. Ni el usuario ni el administrador de la red necesitan introducir las modificaciones manualmente.
En las secciones siguientes se explica la forma en que se realiza la resolución de nombres mediante WINS y los mensajes broadcast.
WINS consta de dos componentes:
Servidor WINS, que maneja las peticiones de consulta y registro de nombres
El software cliente que solicita la resolución de nombres
Los clientes de redes Windows (equipos Windows NT, Windows 98, Windows 95 o Windows para trabajo en grupo 3.11 con software WINS) pueden utilizar WINS directamente. Los equipos de la red que no dispongan de servicios WINS y sean compatibles con el modo b-node (según lo descrito en las especificaciones RFC 1001 y 1002) pueden acceder a WINS a través de proxies (equipos WINS que escuchan las consultas broadcast de nombres y responden con los nombres que no pertenecen a la subred local).
Para posibilitar el examen de la red sin WINS, el administrador debe asegurarse de que el dominio principal de los usuarios dispone de equipos SunLink Server, Windows NT Server o Windows NT Workstation que actúen como examinadores principales a ambos lados del enrutador. Estos equipos tienen que contener archivos LMHOSTS correctamente configurados con entradas para los controladores de dominio de toda la subred.
Con WINS, esta operación no es necesaria porque los servidores y proxies WINS proporcionan de manera transparente el soporte necesario para examinar los distintos extremos del enrutador en dominios que así lo exigen.
Si un cliente Windows NT está preparado para utilizar DHCP y el administrador especifica la información del servidor WINS como parte de las opciones de DHCP, el equipo se configura automáticamente con la información del servidor WINS.
En entornos de resolución de nombres broadcast y WINS, los clientes WINS se comportan de forma distinta a los clientes que no disponen de WINS. Las diferencias se hacen patentes en la forma en que manejan la resolución, registro, liberación y renovación de nombres, tal y como se describe en las secciones siguientes.
Si hay instalados servidores WINS en la "interred", los nombres de equipos NetBIOS se resuelven utilizando dos métodos básicos según esté habilitada o no la resolución WINS en el equipo cliente. Independientemente de cuál sea el método de resolución utilizado, el proceso es transparente para el usuario una vez configurado el sistema.
Si WINS no está habilitado en el cliente - El equipo registra su nombre enviando paquetes de petición de registro (en forma de mensajes broadcast) a la subred local. Para localizar un determinado equipo, el equipo que no dispone de WINS envía paquetes de consulta de nombre (también como mensajes broadcast) a la subred local. Estos mensajes broadcast no pueden atravesar los enrutadores IP. Si la resolución de nombres local falla, consulta el archivo LMHOSTS local. Estos procesos se llevan a cabo tanto si el equipo es un servidor de red, como si es una estación de trabajo u otro dispositivo.
Si WINS está habilitado en el cliente - El equipo consulta primero al servidor WINS. Si esto no da resultado, envía peticiones de registro y consulta de nombres (como mensajes broadcast) siguiendo este procedimiento:
El cliente envía primero una petición de consulta de nombre al servidor WINS. Si éste localiza el nombre en su base de datos, el cliente puede establecer la sesión basándose en la asignación de dirección recibida del servidor WINS.
Si la consulta al servidor WINS no da resultado y el cliente está configurado como h-node, éste envía paquetes de consulta de nombre (como mensajes broadcast) de la misma manera que lo hace un equipo que no dispone de WINS.
Por último, si este otro método falla, consulta el archivo LMHOSTS local (en la búsqueda se incluye cualquier archivo LMHOSTS centralizado al que se haga referencia en las sentencias #INCLUDE de ese archivo local).
Los servidores WINS aceptan y responden a las consultas de nombres UDP (User Datagram Protocol). Cualquier asignación de nombre-dirección IP registrada en un servidor WINS puede suministrarse como respuesta válida a una consulta de nombre, si bien una asignación de esta base de datos no garantiza que el dispositivo asociado esté en funcionamiento, sólo que un equipo tiene asignada esta dirección IP y que, en ese momento, la asignación es válida.
El registro de nombres garantiza que el nombre de equipo NetBIOS y la dirección IP son exclusivos para cada equipo.
Si WINS está habilitado en el cliente - La petición de registro de nombre se envía directamente al servidor WINS para que lo agregue a la base de datos. Este servidor acepta o rechaza la petición de registro en función del contenido de su base de datos y de los criterios siguientes:
Si la base de datos contiene otra dirección para ese nombre, WINS envía un mensaje a la entrada actual para determinar si ese dispositivo todavía reclama ese nombre.
Si hay otro dispositivo que utiliza ese nombre, WINS rechaza la petición de registro del nuevo nombre.
En otros casos, WINS acepta la entrada y la agrega a su base de datos local con una marca de hora, un número de versión exclusivo e incremental y otra información complementaria.
Si WINS no está habilitado en el cliente - Los equipos que no disponen de WINS envían un paquete broadcast de petición de registro de nombre a la red local especificando su nombre de equipo NetBIOS y su dirección IP. Cualquier otro dispositivo que haya reclamado ese nombre con anterioridad rechaza la petición enviando una respuesta negativa que da como resultado el fallo de ese intento de registrar un nombre duplicado. Si la petición de registro de nombre no recibe respuestas negativas durante un determinado tiempo, el equipo que ha enviado la petición adopta ese nombre y esa dirección.
Una vez que un equipo que no utiliza WINS ha reclamado un nombre, debe rechazar cualquier intento de registro de ese mismo nombre (enviando una respuesta de petición de registro negativa) y responder positivamente a cualquier consulta que solicite el nombre que tiene registrado (con una respuesta de petición de consulta de nombre positiva). La respuesta positiva contiene la dirección IP del equipo para que ambos sistemas puedan establecer una sesión.
Cuando un equipo termina de utilizar un determinado nombre, deja de rechazar el registro de ese nombre por parte de otros equipos. Esto se conoce como liberar un nombre.
Si WINS está habilitado en el cliente - Cada vez que se apaga un equipo de forma normal, libera su nombre en el servidor WINS, con lo que la entrada correspondiente en la base de datos se marca como liberada. Si permanece liberada por un determinado periodo de tiempo, el servidor la marca como extinguida, actualiza el número de versión y notifica el cambio a los otros servidores WINS.
Si un nombre está marcado como liberado en un servidor WINS y se recibe una nueva petición de registro con ese nombre pero otra dirección, el servidor puede asignar el nombre inmediatamente al nuevo cliente porque sabe que el cliente anterior ya no lo utiliza. Esto puede ocurrir, por ejemplo, cuando un equipo portátil que utiliza DHCP cambia de subred.
Si el equipo ha liberado su nombre durante un apagado normal, el servidor WINS no rechaza el nombre cuando vuelve a conectarse. Si el apagado no se realiza de forma normal, el intento de registrar el nombre con una nueva dirección provoca que el servidor WINS rechace el registro. El rechazo no da resultado y el nombre queda registrado porque el equipo ya no tiene su antigua dirección.
Si WINS no está habilitado en el cliente - Cuando un equipo que no dispone de WINS libera un nombre, se envía un mensaje broadcast para que cualquier sistema de la red que tenga ese nombre en caché lo suprima. Si los equipos reciben paquetes de consulta del nombre suprimido, hacen caso omiso, lo que permite a otros equipos de la red adoptar el nombre liberado.
Para poder acceder a equipos de otras subredes que no utilizan WINS, sus nombres deben agregarse como entradas estáticas a la base de datos WINS o a los archivos LMHOSTS de los sistemas remotos porque sólo responderán a peticiones originadas en su subred local.
Los equipos clientes deben renovar de forma periódica sus nombres NetBIOS en el servidor WINS. Cuando un cliente se registra por primera vez en dicho servidor, éste le devuelve un mensaje donde indica cuándo debe renovar el registro, siguiendo estos criterios:
El intervalo predeterminado de renovación de entradas de la base de datos WINS es de seis días.
Los clientes WINS se registran y actualizan cada tres días.
Los servidores WINS principal y secundario deben tener los mismos intervalos de renovación.
Las entradas definidas como estáticas no vencen.
Si una entrada es propiedad del servidor WINS local, el nombre se libera en el momento especificado a menos que el cliente la haya renovado. Si la entrada pertenece a otro servidor WINS, se reconfirma en el momento especificado. Si la entrada no existe en la base de datos del servidor WINS propietario de la misma, se elimina de la base de datos WINS local. Las peticiones de renovación de nombre se tratan como un registro de nombre nuevo.
Un ajuste incorrecto del intervalo de renovación puede afectar negativamente al sistema y al rendimiento de la red.
Un proxy de WINS es un equipo con servicios WINS mediante el cual pueden resolverse las consultas de nombre de equipos que no utilizan WINS en intranets TCP/IP enrutadas. Los equipos que no utilizan WINS se configuran de forma predeterminada con el modo b-node, que emplea mensajes broadcast IP para enviar las consultas de nombre. El proxy de WINS escucha la subred local para detectar mensajes broadcast IP de consulta de nombre.
Cuando un equipo que no utiliza WINS envía un mensaje broadcast de consulta de nombre, el proxy de WINS acepta el mensaje y busca en su memoria caché la asociación existente entre el nombre de equipo NetBIOS y la dirección IP. Si el proxy de WINS contiene esta asociación en su caché, envía la información al equipo que ha efectuado la petición. Si no localiza la asociación en su caché, la solicita a un servidor WINS.
Si no hay ningún servidor WINS disponible en la subred local, el proxy de WINS puede efectuar la petición a otro servidor a través del enrutador. Este proxy almacena en memoria caché las asociaciones entre nombres de equipo y direcciones IP recibidas del servidor WINS y las utiliza para posteriores consultas broadcast de nombre procedentes de equipos b-node dentro de la subred local.
Las asociaciones entre nombre y dirección IP que recibe el proxy de WINS se guardan en caché durante un tiempo limitado (el valor predeterminado es seis minutos y el mínimo permitido es un minuto).
Cuando el proxy de WINS recibe una respuesta del servidor WINS, la almacena en su caché y la utiliza para responder a posteriores consultas broadcast de nombre.
La función de un proxy de WINS es similar a la del agente relé DHCP/BOOTP, que reenvía las peticiones de clientes DHCP a través de los enrutadores. Dado que el servidor WINS no responde a los mensajes broadcast, es necesario instalar un equipo configurado como proxy de WINS en subredes con equipos que utilicen este tipo de mensajes para la resolución de nombres.
Para configurar un equipo Windows NT, versión 4.0, como proxy de WINS, es preciso editar manualmente el Registro de ese equipo. La clave EnableProxy debe definirse con el valor 1 (REG_DWORD). Esta clave se almacena en: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Netbt\ Parameters