Editer un article - Informaticien.be

Editer un article

Titre
Mots Clés
Texte	[size=18] [b]Nom[/b] [/size] getnameinfo - Traduction d'adresse en nom de façon indépendante du protocole [size=18] [b]Résumé[/b] [/size] .nf [b]#include <sys/socket.h>[/b] [b]#include <netdb.h>[/b] [b][i]int getnameinfo(const struct sockaddr * sa , socklen_t salen ,[/i][/b] [b][i] char * host , size_t hostlen ,[/i][/b] [b][i] char * serv , size_t servlen , int flags );[/i][/b] .fi [size=18] [b]Description[/b] [/size] La fonction [b]getnameinfo (3)[/b] est définie afin de traduire des adresses en noms de noeuds de façon indépendante du protocole. Elle combine les fonctionnalités de [b]gethostbyaddr (3)[/b] et [b]getservbyport (3)[/b] et constitue la réciproque de [b]getaddrinfo (3).[/b] Le paramètre [i]sa[/i] est un pointeur vers l'adresse d'une structure de socket générique (de type [i]sockaddr_in[/i] ou [b]sockaddr_in6 )[/b] de taille [b]salen[/b] qui contient l'adresse IP d'entrée et le numéro de port. Les parmètres [i]host[/i] et [i]serv[/i] sont des pointeurs vers des tampons (de tailles respectives [i]hostlen[/i] et [i]servlen[/i] ) destinés à recevoir les valeurs renvoyées. L'appelant peut préciser qu'aucun nom d'hôte (ou qu'aucun nom de service) n'est nécessaire en fournissant NULL comme paramètre [i]host[/i] (ou [b]serv )[/b] ou bien en passant un argument [i]hostlen[/i] (ou [b]servlen )[/b] valant zéro. Quoi qu'il en soit, au moins un nom d'hôte ou un nom de service doit être demandé. Le paramètre [i]flags[/i] modifie le comportement de [b]getnameinfo (3)[/b] comme indiqué ci dessous : [b]NI_NOFQDN[/b] [table][row][col]    [/col][col]renvoie seulement la partie nom de l'hôte du FQDN (Fully-Qualified Domain Name) pour les hôtes locaux.[/col][/row][/table] [b]NI_NUMERICHOST[/b] [table][row][col]    [/col][col]La forme numérique du nom de l'hôte est renvoyée. (Même si ce drapeau n'est pas levé, cela arrivera également lorsque le nom du noeud ne pourra pas être résolu.)[/col][/row][/table] [b]NI_NAMEREQD[/b] [table][row][col]    [/col][col]renvoie une erreur si le nom de l'hôte ne peut être résolu.[/col][/row][/table] [b]NI_NUMERICSERV[/b] [table][row][col]    [/col][col]L'adresse du service est renvoyée sous forme numérique, par exemple sous la forme de son numéro de port.[/col][/row][/table] [b]NI_DGRAM[/b] [table][row][col]    [/col][col]Indique que le service est plutôt basé sur des datagrammes (UDP) que sur un flux connecté (TCP). Ce drapeau est nécessaire pour les quelques ports (512-514) qui ont des services différents selon le protocole utilisé : UDP ou TCP.[/col][/row][/table] [size=18] [b]Valeur renvoyée[/b] [/size] En cas de succès, 0 est renvoyé, et, les noms du noeud et du service, s'ils sont demandés, sont renseignés sous forme de chaînes à zéro terminal, éventuellement tronquées afin de s'adapter aux tailles des tampons spécifiés. En cas d'erreur, une valeur non nulle est renvoyée, et [i]errno[/i] est affectée de façon adéquate. [size=18] [b]Erreurs[/b] [/size] [b]EAI_AGAIN[/b] [table][row][col]    [/col][col]Le nom ne peut être résolu en ce moment. Réessayer plus tard.[/col][/row][/table] [b]EAI_BADFLAGS[/b] [table][row][col]    [/col][col]Le paramètre [i]flags[/i] n'est pas valide.[/col][/row][/table] [b]EAI_FAIL[/b] [table][row][col]    [/col][col]Une erreur irrécupérable est survenue.[/col][/row][/table] [b]EAI_FAMILY[/b] [table][row][col]    [/col][col]La famille d'adresse n'a pas été reconnue, ou bien la taille de l'adresse était invalide pour la famille spécifiée.[/col][/row][/table] [b]EAI_MEMORY[/b] [table][row][col]    [/col][col]Pas assez de mémoire.[/col][/row][/table] [b]EAI_NONAME[/b] [table][row][col]    [/col][col]Le nom ne peut être résolu avec les paramètres fournis. NI_NAMEREQD est spécifié et le nom de l'hôte ne peut être localisé, ou bien, on n'a demandé ni un nom d'hôte ni un nom de service.[/col][/row][/table] [b]EAI_SYSTEM[/b] [table][row][col]    [/col][col]Une erreur système a eu lieu. Le code d'erreur peut être lu dans [b]errno .[/b][/col][/row][/table] [size=18] [b]Fichiers[/b] [/size] /etc/hosts [b][/b] /etc/nsswitch.conf [b][/b] /etc/resolv.conf [size=18] [b]Note[/b] [/size] Afin d'aider les programmeurs à choisir des tailles raisonnables pour les tampons fournis, [i]<netdb.h>[/i] définit les constantes[table][row][col]    [/col][col] .nf # define NI_MAXHOST 1025 [b][/b] # define NI_MAXSERV 32 .fi[/col][/row][/table] La première est la constante MAXDNAME présente dans les versions récentes du fichier header [i]<arpa/nameser.h>[/i] de BIND. La deuxième est déterminée en se basant sur les services répertoriés dans la RFC "Assigned numbers" (Numéros affectés) actuelle. [size=18] [b]Exemples[/b] [/size] Le code suivant essaie d'obtenir le nom de l'hôte ainsi que le nom du service sous forme numérique, et ce, pour une adresse de socket donnée. Remarquez qu'il n'y a aucune référence à une quelconque famille d'adresse codée en dur. [table][row][col]    [/col][col] .nf struct sockaddr sa; / input / char hbuf[NI_MAXHOST], sbuf[NI_MAXSERV]; if (getnameinfo(sa, sa->sa_len, hbuf, sizeof(hbuf), sbuf, sizeof(sbuf), NI_NUMERICHOST \| NI_NUMERICSERV) == 0) printf("host=%s, serv=%sen", hbuf, sbuf); .fi[/col][/row][/table] La version suivante vérifie si l'adresse de la socket peut se voir associer un nom. [table][row][col]    [/col][col] .fi struct sockaddr sa; /* input */ char hbuf[NI_MAXHOST]; if (getnameinfo(sa, sa->sa_len, hbuf, sizeof(hbuf), NULL, 0, NI_NAMEREQD)) printf("could not resolve hostname"); else printf("host=%sen", hbuf); .fi[/col][/row][/table] [size=18] [b]Conformité[/b] [/size] RFC 2553. (Voir aussi XNS, révision 5.2.) [size=18] [b]Voir aussi[/b] [/size] [b]getaddrinfo (3),[/b] [b]gethostbyaddr (3),[/b] [b]getservbyname (3),[/b] [b]getservbyport (3),[/b] [b]inet_ntop (3),[/b] [b]socket (3),[/b] [b]hosts (5),[/b] [b]services (5),[/b] [b]hostname (7),[/b] [b]named (8)[/b]     R. Gilligan, S. Thomson, J. Bound et W. Stevens, [b]Basic Socket Interface Extensions for IPv6 ,[/b] RFC 2553, Mars 1999.     Tatsuya Jinmei et Atsushi Onoe, [b]An Extension of Format for IPv6 Scoped Addresses ,[/b] internet draft, travail en cours. ftp://ftp.ietf.org/internet-drafts/draft-ietf-ipngwg-scopedaddr-format-02.txt     Craig Metz, [b]Protocol Independence Using the Sockets API ,[/b] compte rendu du sujet freenix : conférence technique annuelle USENIX 2000, juin 2000. http://www.usenix.org/publications/library/proceedings/usenix2000/freenix/metzprotocol.html [size=18] [b]Traduction[/b] [/size] Stéphan Rafin, 2002.
Fichier