Wenn ein Computer seine IP-Adresse initialisiert hat, registriert er im nächsten Schritt seine NetBIOS-Namen. NetBIOS-Namen werden entweder über B-Knoten-Broadcasts oder mit einem NetBIOS-Namensserver wie z.B. WINS registriert, erneuert, aufgelöst und freigegeben. Dies bietet den Vorteil dass der Verkehr zielgerichtet gesendet wird und nicht über Broadcasts. Alle NetBIOS-Namen über TCP/IP verwenden UDP-Port 137.
NetBIOS-Namen müssen für jeden Dienst oder jede Anwendung registriert werden, die NetBIOS unterstützen. Die tatsächliche Anzahl der Namen hängt von der Anzahl von NetBIOS-Diensten ab, die von einem Client initialisiert werde
Wenn der WINS-Server eine Zuordnung eines NetBIOS-Namens zu einer IP-Adresse findet, sendet er die IP-Adresse des Ziel-Clients direkt an den WINS-Client zurück. Die WINS-Datenbank ist dynamisch, weshalb sie immer auf dem neusten Stand ist.
Warum WINS verwenden
- Anforderungen werden direkt an den WINS-Server gesendet - verringert den Broadcast-Verkehr
- Die WINS-Datenbank wird dynamisch aktualisiert
- WINS bietet die Möglichkeit des Durchsuchens von WAN-Ressourcen und Domänenübergreifenden Ressourcen
Funktionsweise von WINS
Der gesamte WINS-Verkehr wird unter Verwendung von UDP-Datagrammen über Port 137 abgewickelt (NetBIOS-Namensdienst). Wenn ein WINS-Client initialisiert wird, sendet er seinen NetBIOS-Namen direkt an den konfigurierten WINS-Server. Falls in der WINS-Datenbank ein Doppel des zu registrierenden Namens gefunden wird, sendet der WINS-Server eine als Namensabfrage formulierte Abfrage an den zur Zeit registrierten Besitzer des Namens. Der WINS-Server sendet diese Abfrage dreimal in Abständen von 500 Millisekunden aus. Wenn der zur Zeit registrierte Benutzer dem WINS-Server antwortet, sendet der WINS-Server eine negative Namensregistrierungsantwort an den Client der versucht, seinen Namen zu registrieren. Wenn der Client nicht antwortet, wird der Name des anfragenden Clients neu registriert.
Namensregistrierung
Wenn der WINS-Server nicht verfügbar ist
In diesem Fall versucht der Client dreimal unter Verwendung von ARP, den primären WINS-Server zu finden. Nach diesen drei Versuchen sendet er seine Namensregistrierung an den sekundären WINS-Server (falls konfiguriert). Als letztes versucht er seinen Namen mittles Broadcasts zu registrieren (H-Node).
Erneuerung eines Namens
Wenn ein Name mit einem WINS-Server registriert wird, antwortet der Server mit einer Erfolgsmeldung, die eine TTL (Time to live) beinhaltet. Die TTL gibt an, wann der Client seinen Namen erneuern muss. Die Standardkonfiguration eines WINS-Server legt eine TTL von sechs Tagen fest. Ein WINS-Client versucht das erste mal, seinen Namen zu erneuern, wenn ein Achtel seiner Lease abgelaufen ist. Wenn dies nicht funktioniert, wird der Client nun alle drei Minuten versuchen, seinen Namen neu zu registrieren, bis zur Hälfte der TTL. Nach der Hälfte schaltet der Client auf dem sekundären WINS-Server um. Er verhält sich dabei, wie wenn es noch der erste Erneuerungsversuch ist (ein Achtel bis zur Hälfte). Gelingt ihm keine Namenserneuerung, schaltet er wieder auf den primären WINS-Server um. Hat ein Client einmal seinen Namen erfolgreich erneuern können, startet er nachfolgenden Erneuerungen erst nachdem die Hälfte der TTL abgelaufen ist.
Namensabfrage und Namensantwort
Bei der Konfiguration eines WINS-Clients wird standardmässig der Knotentyp H von NetBIOS over TCP/IP implementiert. Dies bedeutet:
- Bei einer Abfrage wird immer zuerst der lokale NetBIOS-Namenscache untersucht
- Wenn der Name unter Punkt eins nicht aufgelöst werden konnte, wird eine direkte Abfrage an den primären WINS-Server gestellt. Falls der primäre WINS-Server nicht verfügbar ist, versucht der Client den Namen über den sekundären WINS-Server aufzulösen
- Wenn kein WINS.-Server den Namen auflösen kann, wird eine negative Abfrageantwort an den WINS-Client gesendet und ein Broadcast wird durchgeführt
- Wenn der Name bislang nicht aufgelöst werden konnte, besteht immer noch die Möglichkeit, dass er durch das LMHOSTS-File, das HOSTS-File oder DNS aufgelöst werden kann
Auswerten von Namen
Der durch die Namensauswertung verursachte Verkehr tritt sehr häufig auf. Zum Auswerten eines NetBIOS-Namens sendet der Client eine Anfrage an den WINS-Server, der den aufzulösenden Namen sowie ein Attribut enthält, dass es sich um eine Abfrage handelt. Aufgelöste Namen bleiben dann standardmässig für 10 Minuten im NetBIOS-Cache des Clients.
Wenn der abgefrage Namen in der WINS-Datenbank vorhanden ist, antwortet der Server mit einem "Name Query Response Datenblock". Der Datenblock enthält ein Attribut, das angibt, dass es sich um eine Rückmeldung einer Abfrage handelt, sowie die IP-Adresse des registrierten Namensinhabers. Ist der Name nicht in WINS registriert, antwortetet der Server mit der Meldung "angeforderter Name nicht vorhanden". In diesem Fall kann ein Client dann z.B. mit Broadcasts versuchen, den Namen aufzulösen.
Freigeben von Namen
Wenn ein Name von einem Computer registriert wurde, ist dieser Host bis zur Freigabe Eigentümer des Namens. Wenn ein Hosts seinen Dienst beendet oder (ordnungsgemäss) heruntergefahren wird, gibt er den Namen beim WINS-Server frei.
Überlegungen zur Implementierung
Für ein Netzwerk mit Subnetzen reicht im Prinzip ein WINS-Server, weil WINS-Abfragen zielgerichtete Datagramme sind, die geroutet werden können. Für den Backupfall sollten aber ein zweiter WINS-Server eingerichtet werden oder bei Bedarf noch weitere. Bei allen WINS-Servern sollte die Protokollierung abgeschaltet werden, weil dadurch der Server viel an Performance gewinnt.
Für alle Clients, die nicht für WINS konfiguriert sind, sollte in der WINS-Datenbank ein statischer Eintrag erstellt werden, damit WINS-Clients mit nicht-WINS-Clients in Remote-Netzwerken kommunizieren können. Weiter sollte in jedem Sunetz, in dem Clienst vorhanden sind, die nicht für WINS konfiguriert sind, ein WINS-Proxy-Agent implementiert werden. WINS-Proxy-Agents fangen NetBIOS-Brodcasts von nicht-WINS-Clients zur Namensauflösung ab und senden diese an den WINS-Server weiter. Bevor der Proxy die Anfrage an den WINS-Server weiterleitet, durchsucht er zuerst seinen lokalen Namenscache. Kann der Proxy den Namen auflösen, sendet er die IP-Adresse an den Client, der den Broadcast ausgelöst hat - andernfalls erhält der WINS-Proxy die IP-Adresse vom WINS-Server. Pro Subnetz können maximal zwei Proxy-Agents installiert werden. Der Proxy-Agent muss ein WINS-Client und kann kein WINS-Server sein. Ein Proxy-Agent muss über die Registrierung konfiguriert werden.
HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\NetBT\Parameters und den Parameter "EnableProxy" auf "1" setzen (REG_DWORD).
Die verschiedenen WINS-Knotentypen
WINS-Clients können für verschiedene Knotentypen konfiguriert werden. Dies hat Auswirkungen darauf, wie Namen aufgelöst werden.
| Term | Definition |
| B-Node | Broadcast-Knoten kommunizieren mit einem Mix aus UDP-Dategrammen und TCP-Verbindungen. B-Knoten versuchen, einen Namen mit einem Broadcast aufzulösen - gelingt dies nicht, kann keine Kommunikation zwischen zwei Rechnern stattfinden. Normalerweise werden NetBIOS-Broadcasts auch nicht geroutet, weil die Ports 137-139 auf den meisten Routern gesperrt sind. B-Knoten verursachen grossen Broadcast-Traffic. |
| P-Node | Ein P-Knoten versucht einzig und allein, Namen über einen WINS-Server aufzulösen (lokal und remote). Es wird kein Broadcast-Verkehr generiert. Ist kein WINS-Server erreichbar, kann keine Kommunikation stattfinden, nicht einmal lokal. |
| M-Node | Dieser Knoten ist ein Mischung aus B- und P-Knoten. Ein Name wird versucht aufzulösen, indem zuerst ein Broadcast, dann eine WINS-Server Abfrage generiert wird. Dieser Knoten verursacht ebenfalls grossen Broadcast-Verkehr, kann aber auch Remote-Abfragen abhandeln. |
| H-Node | Dies sollte der am sinnvollsten verwendete Knotentyp sein. Er ist ebenfalls eine Mischung aus den ersten beiden Knotentypen. Er macht aber zuerst eine Namensabfrage über einen WINS-Server, erst dann über Broadcasts. |
Die folgende Tabelle enthält Namen, die häufig von einem Microsoft-Client auf einem WINS-Server registriert werden.
| Registrierter Name | Beschreibung |
| Computername <00> | Vom Arbeitsstationsdienst des Clients registriert |
| Computername <03> | Vom Nachrichtendienst registriert z.B. für "net send computername" |
| Benutzername <03> | Vom Nachtrichtendienst registriert z.B. für "net send username" |
| Computername <20> | Vom Serverdienst registriert. Dadurch kann der Host Verbindungsanfragen von anderen Hosts empfangen |
| Arbeitsgruppen- oder Domänenname <00> | Dadurch wird der Computer als ein Mitglied der Domäne oder der Arbeitsgruppe registriert |
| Arbeitsgruppen- oder Domänenname <1E> | Wird als Gruppen-NetBIOS-Name registriert und für die Wahl eines Suchdienstes verwendet |
| Domänenname <1B> | Registriert den lokalen Computer als Domain Master-Browser für die Domäne |
| Domänenname <1C> | Registriert den lokalen Computer als einen Domänen-Controller für die Domäne |
| Arbeitsgruppen- oder Domänenname <1D> | Registriert den lokalen Client als den Master-Browser für das lokale Subnet für die Arbeitsgruppe oder Domäne |
Optimierung des WINS-Verkehrs
Deaktivieren unnötiger Dienste - denn, jeder Dienst der NetBIOS unterstützt, muss sich beim WINS-Server registrieren.
Erhöhen des NetBIOS-Namens-Cache. Nach der Auswertung eines Namens wird der Wert im Cache abgelegt. Der Cache wird bei jeder Namensauswertung geprüft, bevor eine Abfrage an einen WINS-Server gesendet wird. Standardmässig verbleiben Einträge für 10 Minuten im Cache.
Verwenden von LMHOSTS - Diese Option ist allerdings nur in sehr kleinen Netzen praktikabel. Es gibt die Möglichkeit einer zentralisierten Verwaltung einer LMHOSTS-Datei. Alle Clients lesen dann von dieser zentralen Datei. Die LMHOSTS-Datei speichert in ASCII-Form Zuordnungen von NetBIOS-Namen zu IP-Adressen und ist an folgendem Ort gespeichert: %systemroot%\system32\drivers\etc
Anpassen des Erneuerungsintervalls (TTL). Die TTL gibt an, wie lange ein Name für einen Client reserviert ist. MS-Clients erneuern ihre Namen standardmässig nach der Hälfte der TTL. Wird jetzt die TTL heraufgesetzt, müssen Namenserneuerungen seltener durchgeführt werden.
WINS-Replikation
Vielerorts wird ein einzelner WINS-Server nicht ausreichen, vor allem wenn sehr viele Netze, Subnetze oder mehrere Lokationen vorhanden sind. Mit der WINS-Replikation werden Datensätze von einem WINS-Server zu einem anderen WINS-Server oder umgekehrt kopiert (je nach Konfiguration). Damit wird also erreicht, dass alle WINS-Server den gleichen Wissenstand erreichen. Der lokale WINS-Server richtet dabei eine TCP/IP-Sitzung über Port 135 zum anderen WINS-Server ein. Für die Übertragung der Datensätze wird der TCP-Port 42 verwendet.
WINS-Replikationspartner können entweder als Push-Partner oder als Pull-Partner konfiguriert werden. Push-Partner senden einen Abgleich an ihre Partner, wenn eine bestimmte Anzahl von Datenbankeinträgen geändert wurde. Pull-Partner dagegen fordern in festgelegten Abständen Aktualisierungen an und wenn sie vom Push-Partner benachrichtigt werden.
Voraussetzungen für den Einsatz von WINS
WINS-Server:
- Windows NT Server
- WINS-Serverdienst
- Statische IP-Adresse, Subnet-Maske und Standardgateway
WINS-Client:
- Windows NT Server oder Workstation, Windows 9x
- Windows für Workgroups 3.11 mit TCP/IP-32
- Microsoft Network Client 3.0
- LAN Manager 2.2c für DOS
- Konfiguriert mit der IP-Adresse eines WINS-Servers
Wichtig: Microsoft empfiehlt dringend, dass ein WINS-Server in der TCP/IP-Konfiguration auf sich selbst als primärer und sekundärer WINS-Server zeigt.