Modèle de résolution de noms
Un espace de noms fait référence à une certaine capacité à associer (au minimum) le protocole et les attributs d’adressage d’un service réseau à un ou plusieurs noms conviviaux. De nombreux espaces de noms sont actuellement largement utilisés, notamment dns (Domain Name System) d’Internet, services de domaine Active Directory, bindery, NetWare Directory Services (NDS) de Novell et X.500. Ces espaces de noms varient considérablement dans la façon dont ils sont organisés et implémentés. Certaines de leurs propriétés sont particulièrement importantes à comprendre du point de vue de la résolution de noms Winsock.
Types d’espaces de noms
Il existe trois types d’espaces de noms différents dans lesquels un service peut être inscrit :
- Dynamique
- statique
- Persistante
Les espaces de noms dynamiques permettent aux services de s’inscrire auprès de l’espace de noms à la volée et aux clients de découvrir les services disponibles au moment de l’exécution. Les espaces de noms dynamiques s’appuient fréquemment sur les diffusions pour indiquer la disponibilité continue d’un service réseau. Les anciens exemples d’espaces de noms dynamiques incluent l’espace de noms SAP (Service Advertising Protocol) utilisé dans un environnement NetWare et l’espace de noms NBP (Name Binding Protocol) utilisé par AppleTalk. L’espace de noms pnrP (Peer Name Resolution Protocol) utilisé sur Windows est un exemple plus récent d’espace de noms dynamique.
Les espaces de noms statiques nécessitent que tous les services soient inscrits à l’avance, c’est-à-dire lors de la création de l’espace de noms. Les fichiers d’hôtes, de protocole et de services utilisés par la plupart des implémentations TCP/IP constituent un exemple d’espace de noms statique. Sur Windows, ces fichiers se trouvent généralement dans le dossier C:\windows\system32\drivers\etc .
Les espaces de noms persistants permettent aux services de s’inscrire auprès de l’espace de noms à la volée. Toutefois, contrairement aux espaces de noms dynamiques, les espaces de noms persistants conservent les informations d’inscription dans un stockage non volatile, où elles restent jusqu’à ce que le service demande leur suppression. Les espaces de noms persistants sont typés par des services d’annuaire tels que X.500 et NDS (NetWare Directory Service). Ces environnements permettent d’ajouter, de supprimer et de modifier des propriétés de service. En outre, l’objet de service représentant le service dans le service d’annuaire peut avoir divers attributs associés au service. L’attribut le plus important pour les applications clientes est les informations d’adressage du service. DNS est un autre exemple d’espace de noms persistant. Bien qu’il existe un moyen programmatique de résoudre les noms DNS à l’aide de Sockets Windows, le fournisseur d’espaces de noms DNS dans Windows ne prend pas en charge l’inscription de nouveaux noms DNS à l’aide de Winsock. Vous devez utiliser les fonctions DNS directement pour inscrire des noms DNS. Pour plus d’informations, consultez référence DNS.
Organisation de l’espace de noms
De nombreux espaces de noms sont organisés hiérarchiquement. Certains, tels que X.500 et NDS, autorisent l’imbrication illimitée. D’autres permettent de combiner les services en un seul niveau de hiérarchie ou de groupe. Il s’agit généralement d’un groupe de travail. Lors de la construction d’une requête, il est souvent nécessaire d’établir un point de contexte dans une hiérarchie d’espaces de noms à partir duquel la recherche va commencer.
Architecture du fournisseur d’espaces de noms
Naturellement, les interfaces programmatiques utilisées pour interroger les différents types d’espaces de noms et inscrire des informations dans un espace de noms (si elles sont prises en charge) diffèrent considérablement. Un fournisseur d’espaces de noms est un logiciel local qui sait comment mapper entre l’espace de noms Winsock SPI et un espace de noms existant (qui peut être implémenté localement ou accessible via le réseau). L’architecture du fournisseur d’espaces de noms est illustrée comme suit :
Notez qu’il est possible pour un espace de noms donné, par exemple DNS, d’avoir plusieurs fournisseurs d’espaces de noms installés sur un ordinateur donné.
Comme mentionné ci-dessus, le terme générique service fait référence à la moitié serveur d’une application cliente/serveur. Dans Winsock, un service est associé à une classe de service, et chaque instance d’un service particulier a un nom de service qui doit être unique au sein de la classe de service. Parmi les exemples de classes de service, citons serveur FTP, SQL Server, XYZ Corp. Employee Info Server, etc. Comme l’illustre l’exemple, certaines classes de service sont bien connues, tandis que d’autres sont uniques et spécifiques à une application verticale particulière. Dans les deux cas, chaque classe de service est représentée par un nom de classe et un identificateur de classe. Le nom de la classe n’a pas nécessairement besoin d’être unique, mais l’identificateur de classe doit l’être. Les identificateurs uniques globaux (GUID) sont utilisés pour représenter les identificateurs de classe de service. Pour les services connus, les noms de classes et les identificateurs de classe (GUID) ont été préalloués, et des macros peuvent être converties entre, par exemple, les numéros de port TCP (dans l’ordre d’octets de l’hôte) et les GUID d’identificateur de classe correspondants. Pour les autres services, le développeur choisit le nom de la classe et utilise l’utilitaire Uuidgen.exe pour générer un GUID pour l’identificateur de classe.
La notion de classe de service existe pour permettre l’établissement d’un ensemble d’attributs qui sont communs à toutes les instances d’un service particulier. Cet ensemble d’attributs est fourni au moment où la classe de service est définie sur Winsock et est appelé informations de schéma de classe de service. Lorsqu’un service est installé et mis à disposition sur un ordinateur hôte, ce service est considéré comme instancié et son nom de service est utilisé pour distinguer une instance particulière du service des autres instances qui peuvent être connues de l’espace de noms.
Notez que l’installation d’une classe de service doit se produire uniquement sur les ordinateurs où le service s’exécute, et non sur tous les clients qui peuvent utiliser le service. Lorsque cela est possible, le Ws2_32.dll fournit des informations de schéma de classe de service à un fournisseur d’espaces de noms au moment où une instanciation d’un service doit être inscrite ou une requête de service est lancée. Bien sûr, le Ws2_32.dll ne stocke pas ces informations elle-même, mais tente de les récupérer à partir d’un fournisseur d’espaces de noms qui a indiqué sa capacité à fournir ces données. Étant donné qu’il n’existe aucune garantie que le Ws2_32.dll puisse fournir le schéma de classe de service, les fournisseurs d’espaces de noms qui ont besoin de ces informations doivent disposer d’un mécanisme de secours pour les obtenir par des moyens spécifiques à l’espace de noms.
Comme indiqué ci-dessus, Internet a adopté ce que l’on peut appeler un modèle de service centré sur l’hôte. Les applications qui doivent localiser l’adresse de transport d’un service doivent généralement d’abord résoudre l’adresse d’un hôte spécifique connu pour héberger le service. À cette adresse, ils ajoutent le numéro de port connu et créent ainsi une adresse de transport complète. Pour faciliter la résolution des noms d’hôtes, un identificateur de classe de service spécial a été préalloué (SVCID_HOSTNAME). Une requête qui spécifie SVCID_HOSTNAME comme classe de service et spécifie un nom d’hôte pour le nom de instance du service retourne les informations d’adresse de l’hôte si la requête réussit.
Dans Windows Sockets 2, les applications indépendantes du protocole doivent éviter d’avoir à comprendre les détails internes d’une adresse de transport. Ainsi, la nécessité d’obtenir d’abord une adresse d’hôte, puis d’ajouter dans le port est problématique. Pour éviter cela, les requêtes peuvent également inclure le nom bien connu d’un service particulier et le protocole sur lequel le service fonctionne, par exemple FTP sur TCP. Dans ce cas, une requête réussie retourne une adresse de transport complète pour le service spécifié sur l’hôte indiqué, et l’application n’est pas tenue d’inspecter les éléments internes d’une structure sockaddr .
Le système de noms de domaine d’Internet ne dispose pas d’un moyen bien défini de stocker les informations de schéma de classe de service. Par conséquent, les fournisseurs d’espaces de noms DNS pour Winsock peuvent uniquement prendre en charge les services TCP/IP connus pour lesquels un GUID de classe de service a été préalloué.
Dans la pratique, il ne s’agit pas d’une limitation sérieuse, car les GUID de classe de service ont été préalloués pour l’ensemble des ports TCP et UDP, et des macros sont disponibles pour récupérer le GUID associé à n’importe quel port TCP ou UDP avec le port exprimé dans l’ordre d’octet hôte. Ainsi, tous les services familiers tels que HTTP, FTP, Telnet, Whois, etc. sont bien pris en charge.
Pour poursuivre avec notre exemple de classe de service, instance noms du service FTP peuvent être « alder.intel.com » ou « ftp.microsoft.com », tandis qu’un instance de XYZ Corp. Employee Info Server peut être nommé « XYZ Corp. Employee Info Server version 3.5 ».
Dans les deux premiers cas, la combinaison du GUID de la classe de service pour FTP et du nom de l’ordinateur (fourni en tant que nom de instance de service) identifie de façon unique le service souhaité. Dans le troisième cas, le nom d’hôte où réside le service peut être découvert au moment de la requête du service, de sorte que le nom de instance du service n’a pas besoin d’inclure un nom d’hôte.
Rubriques connexes