Freigeben über


Namensauflösungsmodell

Ein Namespace bezieht sich auf eine Funktion zum Zuordnen (mindestens) des Protokolls und der Adressierungsattribute eines Netzwerkdiensts mit einem oder mehreren Anzeigenamen. Viele Namespaces werden derzeit häufig verwendet, darunter das Domain Name System (DNS) des Internets, Active Directory Domain Services, die Bindery, NetWare Directory Services (NDS) von Novell und X.500. Diese Namespaces unterscheiden sich stark in der Organisation und Implementierung. Einige ihrer Eigenschaften sind besonders wichtig, um aus der Perspektive der Winsock-Namensauflösung zu verstehen.

Namespacetypen

Es gibt drei verschiedene Arten von Namespaces, in denen ein Dienst registriert werden kann:

  • Dynamisch
  • statischen
  • Beständig

Dynamische Namespaces ermöglichen es Diensten, sich sofort mit dem Namespace zu registrieren, und clients können die verfügbaren Dienste zur Laufzeit ermitteln. Dynamische Namespaces basieren häufig auf Broadcasts, um die fortgesetzte Verfügbarkeit eines Netzwerkdiensts anzuzeigen. Ältere Beispiele für dynamische Namespaces sind der SAP-Namespace (Service Advertising Protocol), der in einer NetWare-Umgebung verwendet wird, und der NBP-Namespace (Name Binding Protocol), der von AppleTalk verwendet wird. Der unter Windows verwendete PNRP-Namespace (Peer Name Resolution Protocol) ist ein neueres Beispiel für einen dynamischen Namespace.

Statische Namespaces erfordern, dass alle Dienste im Voraus registriert werden, d. h. beim Erstellen des Namespaces. Ein Beispiel für einen statischen Namespace sind die Hosts, Protokolle und Dienstedateien , die von den meisten TCP/IP-Implementierungen verwendet werden. Unter Windows befinden sich diese Dateien in der Regel im Ordner C:\windows\system32\drivers\etc .

Persistente Namespaces ermöglichen es Diensten, sich beim Namespace direkt zu registrieren. Im Gegensatz zu dynamischen Namespaces behalten persistente Namespaces jedoch die Registrierungsinformationen im nicht flüchtigen Speicher bei, wo sie bis zu dem Zeitpunkt verbleiben, zu dem der Dienst die Entfernung anfordert. Persistente Namespaces werden durch Verzeichnisdienste wie X.500 und den NDS (NetWare Directory Service) typisiert. Diese Umgebungen ermöglichen das Hinzufügen, Löschen und Ändern von Diensteigenschaften. Darüber hinaus kann das Dienstobjekt, das den Dienst innerhalb des Verzeichnisdiensts darstellt, eine Vielzahl von Attributen aufweisen, die dem Dienst zugeordnet sind. Das wichtigste Attribut für Clientanwendungen sind die Adressinformationen des Diensts. DNS ist ein weiteres Beispiel für einen persistenten Namespace. Obwohl es eine programmgesteuerte Möglichkeit gibt, DNS-Namen mithilfe von Windows Sockets aufzulösen, unterstützt der DNS-Namespaceanbieter in Windows die Registrierung neuer DNS-Namen mit Winsock nicht. Sie müssen die DNS-Funktionen direkt verwenden, um DNS-Namen zu registrieren. Weitere Informationen finden Sie in der DNS-Referenz.

Namespaceorganisation

Viele Namespaces sind hierarchisch angeordnet. Einige, z. B. X.500 und NDS, ermöglichen unbegrenztes Schachteln. Andere ermöglichen die Kombination von Diensten in einer einzelnen Hierarchie- oder Gruppenebene. Dies wird in der Regel als Arbeitsgruppe bezeichnet. Beim Erstellen einer Abfrage muss häufig ein Kontextpunkt innerhalb einer Namespacehierarchie festgelegt werden, von der aus die Suche beginnt.

Namespaceanbieterarchitektur

Natürlich unterscheiden sich die programmgesteuerten Schnittstellen, die zum Abfragen der verschiedenen Namespacetypen und zum Registrieren von Informationen innerhalb eines Namespace (sofern unterstützt) verwendet werden. Ein Namespaceanbieter ist eine lokal ansässige Software, die weiß, wie zwischen dem Winsock-Namespace SPI und einem vorhandenen Namespace (der lokal implementiert oder über das Netzwerk zugegriffen werden kann) zugeordnet werden kann. Die Architektur des Namespaceanbieters wird wie folgt veranschaulicht:

Architektur des Namespaceanbieters

Beachten Sie, dass für einen bestimmten Namespace, z. B. DNS, mehrere Namespaceanbieter auf einem bestimmten Computer installiert sind.

Wie oben erwähnt, bezieht sich der generische Begriff Dienst auf die Serverhälfte einer Client-/Serveranwendung. In Winsock ist ein Dienst einer Dienstklasse zugeordnet, und jede instance eines bestimmten Diensts verfügt über einen Dienstnamen, der innerhalb der Dienstklasse eindeutig sein muss. Beispiele für Dienstklassen sind FTP-Server, SQL Server, XYZ Corp. Employee Info Server usw. Wie das Beispiel zu veranschaulichen versucht, sind einige Dienstklassen bekannt, während andere eindeutig und spezifisch für eine bestimmte vertikale Anwendung sind. In beiden Fällen wird jede Dienstklasse sowohl durch einen Klassennamen als auch durch einen Klassenbezeichner dargestellt. Der Klassenname muss nicht unbedingt eindeutig sein, aber der Klassenbezeichner muss sein. Globally Unique Identifiers (GUIDs) werden verwendet, um Dienstklassenbezeichner darzustellen. Für bekannte Dienste wurden Klassennamen und Klassenbezeichner (GUIDs) vorab zugeordnet, und Makros sind verfügbar, um z. B. TCP-Portnummern (in Host-Byte-Reihenfolge) und den entsprechenden Klassenbezeichner-GUIDs zu konvertieren. Für andere Dienste wählt der Entwickler den Klassennamen aus und verwendet das Hilfsprogramm Uuidgen.exe, um eine GUID für den Klassenbezeichner zu generieren.

Der Begriff einer Dienstklasse ist vorhanden, um eine Reihe von Attributen festzulegen, die von allen Instanzen eines bestimmten Diensts gemeinsam gehalten werden. Dieser Satz von Attributen wird zum Zeitpunkt der Definition der Dienstklasse für Winsock bereitgestellt und als Dienstklassenschemainformationen bezeichnet. Wenn ein Dienst installiert und auf einem Hostcomputer zur Verfügung gestellt wird, wird dieser Dienst als instanziiert betrachtet, und sein Dienstname wird verwendet, um eine bestimmte instance des Diensts von anderen Instanzen zu unterscheiden, die dem Namespace möglicherweise bekannt sind.

Beachten Sie, dass die Installation einer Dienstklasse nur auf Computern erfolgen muss, auf denen der Dienst ausgeführt wird, nicht auf allen Clients, die den Dienst möglicherweise nutzen. Die Ws2_32.dll stellt einem Namespaceanbieter nach Möglichkeit Informationen zum Dienstklassenschema bereit, wenn eine Instanziierung eines Diensts registriert oder eine Dienstabfrage initiiert wird. Der Ws2_32.dll speichert diese Informationen natürlich nicht selbst, sondern versucht, sie von einem Namespaceanbieter abzurufen, der seine Fähigkeit zum Bereitstellen dieser Daten angegeben hat. Da es keine Garantie dafür gibt, dass der Ws2_32.dll das Dienstklassenschema bereitstellen kann, müssen Namespaceanbieter, die diese Informationen benötigen, über einen Fallbackmechanismus verfügen, um sie mit namespacespezifischen Mitteln abzurufen.

Wie oben erwähnt, hat das Internet ein sogenanntes hostorientiertes Dienstmodell übernommen. Anwendungen, die die Transportadresse eines Diensts suchen müssen, müssen in der Regel zuerst die Adresse eines bestimmten Hosts auflösen, der für den Host des Diensts bekannt ist. Zu dieser Adresse fügen sie die bekannte Portnummer hinzu und erstellen so eine vollständige Transportadresse. Um die Auflösung von Hostnamen zu erleichtern, wurde ein spezieller Dienstklassenbezeichner vorab zugewiesen (SVCID_HOSTNAME). Eine Abfrage, die SVCID_HOSTNAME als Dienstklasse angibt und einen Hostnamen für den Dienst angibt, instance Name hostadresseninformationen zurückgibt, wenn die Abfrage erfolgreich ist.

In Windows Sockets 2 sollten Anwendungen, die protokollunabhängig sind, vermeiden, dass die internen Details einer Transportadresse verstanden werden müssen. Daher ist die Notwendigkeit, zuerst eine Hostadresse abzurufen und dann den Port hinzuzufügen, problematisch. Um dies zu vermeiden, können Abfragen auch den bekannten Namen eines bestimmten Diensts und das Protokoll enthalten, über das der Dienst ausgeführt wird, z. B. FTP über TCP. In diesem Fall gibt eine erfolgreiche Abfrage eine vollständige Transportadresse für den angegebenen Dienst auf dem angegebenen Host zurück, und die Anwendung muss die Internen einer Sockaddr-Struktur nicht überprüfen.

Das Domänennamensystem des Internets verfügt nicht über eine klar definierte Methode zum Speichern von Dienstklassenschemainformationen. Daher können DNS-Namespaceanbieter für Winsock nur bekannte TCP/IP-Dienste aufnehmen, für die eine Dienstklassen-GUID vorab zugewiesen wurde.

In der Praxis stellt dies keine ernsthafte Einschränkung dar, da dienstklassen-GUIDs für den gesamten Satz von TCP- und UDP-Ports vorab zugewiesen wurden und Makros zum Abrufen der GUID verfügbar sind, die einem TCP- oder UDP-Port mit dem port in Host-Byte-Reihenfolge zugeordnet ist. So sind alle bekannten Dienste wie HTTP, FTP, Telnet, Whois usw. werden gut unterstützt.

Wenn Sie mit unserem Dienstklassenbeispiel fortfahren, können instance Namen des FTP-Diensts "alder.intel.com" oder "ftp.microsoft.com" lauten, während ein instance des XYZ Corp. Employee Info Servers den Namen "XYZ Corp. Employee Info Server Version 3.5" haben kann.

In den ersten beiden Fällen identifiziert die Kombination aus der Dienstklasse-GUID für FTP und dem Computernamen (als Dienst instance Name angegeben) den gewünschten Dienst eindeutig. Im dritten Fall kann der Hostname, in dem sich der Dienst befindet, zur Dienstabfragezeit ermittelt werden, sodass der Dienst instance Name keinen Hostnamen enthalten muss.

DNS-Referenz

Namensauflösungsdatenstrukturen

Protokollunabhängige Namensauflösung

Registrierung und Namensauflösung

SOCKADDR

Zusammenfassung der Namensauflösungsfunktionen