Editer un article - Informaticien.be

Editer un article

Titre
Mots Clés
Texte	[size=18] [b]Nom[/b] [/size] accept - Accepter une connexion sur une socket. [size=18] [b]Résumé[/b] [/size] [b]#include <sys/types.h>[/b] [b][/b] [b]#include <sys/socket.h>[/b] [b][i]int accept(int sock , struct sockaddr * adresse , socklen_t * longueur );[/i][/b] [size=18] [b]Description[/b] [/size] [b]accept[/b] est utilisé généralement avec des processus serveurs orientés-connexion. Cet appel système est employé avec les sockets utilisant un protocole en mode connecté [b]( SOCK_STREAM ,[/b] [b]SOCK_SEQPACKET[/b] et [b]SOCK_RDM )[/b] Il extrait la première connexion de la file des connexions en attente, crée une nouvelle socket avec essentiellement les mêmes propriétés que [i]sock[/i] et alloue pour cette socket un nouveau descripteur de fichier qu'il renvoie. La nouvelle socket n'est plus en état d'écoute. La socket originale [i]sock[/i] n'est pas modifiée par l'appel-système. Remarquez que les attributs du descripteur de fichier (tout ce qu'on peut configurer avec l'option [b]F_SETFL [/b] de fcntl() comme l'état non-bloquant ou asynchrone), ne sont pas hérités durant un [b]accept .[/b] L'argument [i]sock[/i] est une socket qui a été créée avec la fonction [b]socket (2).[/b] attachée à une adresse avec [b]bind (2).[/b] et attend des connextions après un appel [b]listen (2).[/b] L'argument [i]adresse[/i] est un pointeur sur une structure sockaddr. La structure sera remplie avec l'adresse du correspondant se connectant, telle qu'elle est connue par la couche de communication. Le format exact du paramètre [i]adresse[/i] dépend du domaine dans lequel la communication s'établit. (Voir [b]socket (2)[/b] et la page de manuel correspondant au protocole). L'argument [i]longueur[/i] est un paramètre-résultat : il doit contenir initialement la taille de la structure pointée par [b]adresse ,[/b] et est renseigné au retour par la longueur réelle (en octet) de l'adresse remplie. Quand [i]adresse[/i] vaut NULL, rien n'est rempli. S'il n'y a pas de connexion en attente dans la file, et si la socket n'est pas marquée comme non-bloquante, [b]accept[/b] se met en attente d'une connexion. Si la socket est non-bloquante, et qu'aucune connexion n'est présente dans la file, [b]accept[/b] retourne une erreur EAGAIN. Pour être prévenu de l'arrivée d'une connexion sur une socket on peut utiliser [b]select (2)[/b] ou [b]poll (2).[/b] Un évènement "lecture" sera délivré lorsqu'une tentative de connexion aura lieu, et on pourra alors appeler [b]accept[/b] pour la valider. Autrement, on peut configurer la socket pour qu'elle envoie un signal [b]SIGIO[/b] lorsqu'une activité la concernant se produit, voir [b]socket (7)[/b] pour plus de détails. Pour certains protocoles nécessitant une confirmation explicite, comme DECNet, [b]accept[/b] peut être considéré comme extrayant simplement la connexion suivante de la file, sans demander de confirmation. On peut effectuer la confirmation par une simple lecture ou écriture sur le nouveau descripteur, et le rejet en fermant la nouvelle socket. Pour le moment, seul DECNet se comporte ainsi sous Linux. [size=18] [b]Notes[/b] [/size] Il n'y a pas nécessairement de connexion en attente après la réception de [b]SIGIO[/b] ou après que [b]select (2)[/b] ou [b]poll (2)[/b] indiquent quelque chose à lire. En effet la connexion peut avoir été annulée à cause d'une erreur réseau asynchrone ou par un autre thread avant que [b]accept[/b] ne se termine. Si cela se produit, l'appel bloquera en attendant une autre connexion. Pour s'assurer que [b]accept[/b] ne bloquera jamais, la socket [i]sock[/i] transmise doit avoir l'attribut [b]O_NONBLOCK[/b] (voir [b]socket (7)).[/b] [size=18] [b]Valeur renvoyée[/b] [/size] L'appel renvoie -1 en cas d'erreur. S'il réussit il renvoie un entier non-négatif, constituant un descripteur pour la nouvelle socket. [size=18] [b]Gestion des erreurs[/b] [/size] Sous Linux, [b]accept[/b] renvoie les erreurs réseau déjà en attente sur la socket comme une erreur de l'appel-système. Ce comportement diffère d'autres implémentations des sockets BSD. Pour un comportement fiable, une application doit détecter les erreurs réseau définies par le protocole après le [b]accept[/b] et les traiter comme des erreurs [b]EAGAIN ,[/b] en réitérant le mécanisme. Dans le cas de TCP/IP, ces erreurs sont [b]ENETDOWN ,[/b] [b]EPROTO ,[/b] [b]ENOPROTOOPT ,[/b] [b]EHOSTDOWN ,[/b] [b]ENONET ,[/b] [b]EHOSTUNREACH ,[/b] [b]EOPNOTSUPP ,[/b] et [b]ENETUNREACH .[/b] [size=18] [b]Erreurs[/b] [/size] [b]accept[/b] doit échouer si : [b]EAGAIN ou EWOULDBLOCK[/b] [table][row][col]    [/col][col]La socket est non-bloquante et aucune connexion n'est présente dans la file.[/col][/row][/table] [b]EBADF[/b] [table][row][col]    [/col][col]Le descripteur est invalide.[/col][/row][/table] [b]ENOTSOCK[/b] [table][row][col]    [/col][col]Le descripteur n'est pas celui d'une socket.[/col][/row][/table] [b]EOPNOTSUPP[/b] [table][row][col]    [/col][col]La socket de référence n'est pas de type [b]SOCK_STREAM . [/b][/col][/row][/table] [b]EINTR[/b] [table][row][col]    [/col][col]L'appel-système a été interrompu par l'arrivée d'un signal avant qu'une connexion valide ne survienne.[/col][/row][/table] [b]ECONNABORTED[/b] [table][row][col]    [/col][col]Une connexion a été abandonnée.[/col][/row][/table] [b]EINVAL[/b] [table][row][col]    [/col][col]La socket n'est pas en attente de connexions.[/col][/row][/table] [b]EMFILE[/b] [table][row][col]    [/col][col]La limite des descripteurs ouverts pour le processus a été atteinte.[/col][/row][/table] [b]ENFILE[/b] [table][row][col]    [/col][col]Le nombre maximal de descripteurs sur le système a été atteint.[/col][/row][/table] [b]accept[/b] peut échouer si : [b]EFAULT[/b] [i]adresse[/i] [table][row][col]    [/col][col]n'est pas dans l'espace d'adressage accessible en écriture.[/col][/row][/table] [b]ENOBUFS, ENOMEM[/b] [table][row][col]    [/col][col]Par assez de mémoire disponible. En général, cette erreur due à la taille limitée du buffer des sockets, et pas à la mémoire système proprement dite.[/col][/row][/table] [b]EPROTO[/b] [table][row][col]    [/col][col]Erreur de protocole.[/col][/row][/table] La version Linux de [b]accept[/b] peut échouer si : [b]EPERM[/b] [table][row][col]    [/col][col]Les règles du firewall interdisent la connexion.[/col][/row][/table] De plus il peut se produire des erreurs réseau dépendant du protocole de la socket. Certains noyaux Linux peuvent renvoyer d'autres erreurs comme [b]ENOSR,[/b] [b]ESOCKTNOSUPPORT ,[/b] [b]EPROTONOSUPPORT ,[/b] [b]ETIMEDOUT.[/b] L'erreur [b]ERESTARTSYS[/b] peut être rencontrée durant un suivi dans un débogueur. [size=18] [b]Conformité[/b] [/size] SVr4, BSD 4.4 (La fonction [b]accept[/b] est apparue dans BSD 4.2). La page de manuel BSD documente cinq erreurs possibles (EBADF, ENOTSOCK, EOPNOTSUPP, EWOULDBLOCK, EFAULT). SUSv3 documente les erreurs EAGAIN, EBADF, ECONNABORTED, EINTR, EINVAL, EMFILE, ENFILE, ENOBUFS, ENOMEM, ENOTSOCK, EOPNOTSUPP, EPROTO, EWOULDBLOCK, De Plus, SUSv2 documentait EFAULT et ENOSR.     La version Linux de [b]accept[/b] ne fait [b]pas[/b] hériter les attributs comme [b]O_NONBLOCK .[/b] Ce comportement est différent d'autres implémentations BSD. Les programmes portables ne doivent pas s'appuyer sur cette particularité, et doivent reconfigurer les attributs sur la socket renvoyée par accept. [size=18] [b]Note[/b] [/size] Le troisième argument de [b]accept[/b] était, à l'origine, déclaré comme un `int ' (ceci dans libc4 et libc5 ainsi que pour beaucoup d'autres systèmes comme BSD 4., SunOS 4, SGI). Une proposition de standard POSIX 1003.1g l'a modifié en `size_t ' et c'est ce qu'utilise SunOS. Les dernières propositions POSIX en ont fait un `socklen_t ', ce que suivent les spécifications Single Unix, et la glibc2. Pour citer Linus Torvalds: [i]_Toute_[/i] bibliothèque sensée _doit_ garder "socklen_t" équivalent à un int. Toute autre chose invaliderait tout le niveau des sockets BSD. POSIX l'avait d'abord remplacé par un size_t, et je m'en suis plaint violemment (ainsi que d'autres heureusement, mais bien entendu pas tant que ça). Le remplacement par un size_t est complètement inutile car size_t à exactement la même taille qu'un int sur les architectures 64 bits par exemple. Et il _a_ la même taille qu'un "int" parce que c'était l'interface des sockets BSD. Quoiqu'il en soit, les gens de POSIX ont compris et ont créé un "socklen_t". Ils n'auraient jamais dû y toucher, mais une fois commencé, ils ont décidé de créer un type spécifique, pour des raisons inavouées (probablement quelqu'un qui ne veut pas perdre la face en expliquant que le premier travail était stupide et ils ont simplement renommé leur bricolage). [size=18] [b]Voir aussi[/b] [/size] [b]bind (2),[/b] [b]connect (2),[/b] [b]listen (2),[/b] [b]select (2),[/b] [b]socket (2)[/b] [size=18] [b]Traduction[/b] [/size] Christophe Blaess, 1996-2003.
Fichier