Hinweis
Für den Zugriff auf diese Seite ist eine Autorisierung erforderlich. Sie können versuchen, sich anzumelden oder das Verzeichnis zu wechseln.
Für den Zugriff auf diese Seite ist eine Autorisierung erforderlich. Sie können versuchen, das Verzeichnis zu wechseln.
Ein Namespace bezieht sich auf einige Funktionen zum Zuordnen (mindestens) des Protokolls und der Adressierung von Attributen eines Netzwerkdiensts mit einem oder mehreren Anzeigenamen. Viele Namespaces werden derzeit häufig verwendet, darunter das Domain Name System (DNS), Active Directory Domain Services, die Bindery, NetWare Directory Services (NDS) aus Novell und X.500. Diese Namespaces unterscheiden sich stark darin, wie sie organisiert und implementiert werden. Einige ihrer Eigenschaften sind besonders wichtig, um aus der Perspektive der Winsock-Namensauflösung zu verstehen.
Namespacetypen
Es gibt drei verschiedene Namespacetypen, in denen ein Dienst registriert werden kann:
- Dynamisch
- Statisch
- Beharrlich
Dynamische Namespaces ermöglichen es Diensten, sich dynamisch mit dem Namespace zu registrieren, und damit Clients die verfügbaren Dienste zur Laufzeit ermitteln können. Dynamische Namespaces basieren häufig auf Übertragungen, um die fortgesetzte Verfügbarkeit eines Netzwerkdiensts anzugeben. Ältere Beispiele für dynamische Namespaces sind der SAP-Namespace (Service Advertising Protocol), der in einer NetWare-Umgebung verwendet wird, und den von AppleTalk verwendeten NBP-Namespace (Name Binding Protocol). 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 vorab registriert werden, d. h., wenn der Namespace erstellt wird. Ein Beispiel für einen statischen Namespace sind die Hosts, Protokoll-und Dienste Dateien, die von den meisten TCP/IP-Implementierungen verwendet werden. Unter Windows befinden sich diese Dateien in der Regel im C:\windows\system32\drivers\etc Ordner.
Persistente Namespaces ermöglichen es Diensten, sich im Fly-On-Fly-Namespace mit dem Namespace zu registrieren. Im Gegensatz zu dynamischen Namespaces behalten persistente Namespaces jedoch die Registrierungsinformationen im nicht unvolatile Speicher bei, wo sie verbleiben, bis die Dienstanforderungen, die entfernt werden. Persistente Namespaces werden von Verzeichnisdiensten wie X.500 und dem NDS (NetWare Directory Service) eingegeben. Diese Umgebungen ermöglichen das Hinzufügen, Löschen und Ändern von Diensteigenschaften. Darüber hinaus könnte 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 ist die Adressierungsinformationen des Diensts. DNS ist ein weiteres Beispiel für einen persistenten Namespace. Obwohl es eine programmgesteuerte Möglichkeit gibt, DNS-Namen mit Windows Sockets aufzulösen, unterstützt der DNS-Namespaceanbieter in Windows nicht das Registrieren neuer DNS-Namen mithilfe von Winsock. Sie müssen die DNS-Funktionen direkt verwenden, um DNS-Namen zu registrieren. Weitere Informationen finden Sie im DNS Reference.
Namespaceorganisation
Viele Namespaces sind hierarchisch angeordnet. Einige, z. B. X.500 und NDS, ermöglichen eine unbegrenzte Schachtelung. Andere ermöglichen die Kombination von Diensten in eine einzelne Hierarchie- oder Gruppenebene. Dies wird in der Regel als Arbeitsgruppebezeichnet. Beim Erstellen einer Abfrage ist es häufig erforderlich, einen Kontextpunkt in einer Namespacehierarchie einzurichten, von der die Suche beginnt.
Namespaceanbieterarchitektur
Natürlich unterscheiden sich die programmgesteuerten Schnittstellen, die zum Abfragen der verschiedenen Namespacetypen und zum Registrieren von Informationen in einem Namespace (sofern unterstützt) verwendet werden. Ein Namespaceanbieter ist ein lokal ansässiger Softwareteil, der weiß, wie zwischen dem Winsock-Namespace SPI und einem vorhandenen Namespace (der lokal implementiert oder über das Netzwerk aufgerufen werden kann) zugeordnet werden kann. Die Namespaceanbieterarchitektur wird wie folgt veranschaulicht:
Beachten Sie, dass es für einen bestimmten Namespace möglich ist, z. B. DNS, mehrere Namespaceanbieter auf einem bestimmten Computer installiert zu haben.
Wie bereits erwähnt, bezieht sich der generische Begriff Dienst auf die Serverhälfte einer Client-/Serveranwendung. In Winsock ist ein Dienst einer Dienstklassezugeordnet, und jede Instanz 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 zeigt, 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. GUIDs (Globally Unique Identifiers) werden verwendet, um Dienstklassenbezeichner darzustellen. Für bekannte Dienste wurden Klassennamen und Klassenbezeichner (GUIDs) bereits zugewiesen, und Makros stehen zur Konvertierung zwischen z. B. TCP-Portnummern (in Hostbytereihenfolge) und den entsprechenden Klassenbezeichner-GUIDs zur Verfügung. Bei anderen Diensten 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 besteht darin, 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 wird als Dienstklassenschemainformationen bezeichnet. Wenn ein Dienst auf einem Hostcomputer installiert und verfügbar gemacht wird, wird dieser Dienst als instanziiertbetrachtet, und sein Dienstname wird verwendet, um eine bestimmte Instanz des Diensts von anderen Instanzen zu unterscheiden, die dem Namespace bekannt sein können.
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 nutzen können. Wenn möglich, stellt die Ws2_32.dll Dienstklassenschemainformationen für einen Namespaceanbieter bereit, wenn eine Instanziierung eines Diensts registriert werden soll oder eine Dienstabfrage initiiert wird. Die Ws2_32.dll speichert diese Informationen natürlich nicht selbst, sondern versucht, sie von einem Namespaceanbieter abzurufen, der die Fähigkeit zum Bereitstellen dieser Daten angegeben hat. Da es keine Garantie gibt, dass die Ws2_32.dll das Dienstklassenschema bereitstellen kann, müssen Namespaceanbieter, die diese Informationen benötigen, über einen Fallbackmechanismus verfügen, um sie über namespacespezifische Mittel abzurufen.
Wie bereits erwähnt, hat das Internet übernommen, was als hostorientiertes Dienstmodell bezeichnet werden kann. Anwendungen, die die Transportadresse eines Diensts suchen müssen, müssen im Allgemeinen zuerst die Adresse eines bestimmten Hosts auflösen, der als Host für den Dienst bekannt ist. An diese Adresse fügen sie die bekannte Portnummer hinzu und erstellen damit eine vollständige Transportadresse. Um die Auflösung von Hostnamen zu erleichtern, wurde ein spezieller Dienstklassenbezeichner vorverteilt (SVCID_HOSTNAME). Eine Abfrage, die SVCID_HOSTNAME als Dienstklasse angibt und einen Hostnamen für den Namen der Dienstinstanz angibt, gibt Hostadresseninformationen zurück, wenn die Abfrage erfolgreich ist.
In Windows Sockets 2 sollten anwendungen, die protokollunabhängig sind, die Notwendigkeit vermeiden, die internen Details einer Transportadresse zu verstehen. 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 ist nicht erforderlich, um die Internen einer sockaddr Struktur zu prüfen.
Das Domänennamensystem des Internets verfügt nicht über eine gut definierte Möglichkeit 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 ist dies keine ernste Einschränkung, da Dienstklassen-GUIDs für den gesamten Satz von TCP- und UDP-Ports vorab zugewiesen wurden, und Makros sind verfügbar, um die GUID abzurufen, die mit einem beliebigen TCP- oder UDP-Port mit dem port in Host-Byte-Reihenfolge angegeben ist. Daher werden alle vertrauten Dienste wie HTTP, FTP, Telnet, Whois usw. gut unterstützt.
Wenn Sie mit unserem Dienstklassenbeispiel fortfahren, können Instanznamen des FTP-Diensts "alder.intel.com" oder "ftp.microsoft.com" lauten, während eine Instanz des XYZ Corp. Employee Info Server möglicherweise den Namen "XYZ Corp. Employee Info Server Version 3.5" hat.
In den ersten beiden Fällen identifizieren die Kombination der Dienstklassen-GUID für FTP und den Computernamen (angegeben als Dienstinstanzname) den gewünschten Dienst eindeutig. Im dritten Fall kann der Hostname, in dem sich der Dienst befindet, zur Dienstabfragezeit ermittelt werden, sodass der Name der Dienstinstanz keinen Hostnamen enthalten muss.
Verwandte Themen