Provided by:
manpages-fr-dev_3.27fr1.4-1_all 
NOM
accept - Accepter une connexion sur une socket
SYNOPSIS
#include <sys/types.h> /* Consultez NOTES */
#include <sys/socket.h>
int accept(int sockfd, struct sockaddr *addr, socklen_t *addrlen);
#define _GNU_SOURCE /* Consultez feature_test_macros(7) */
#include <sys/socket.h>
int accept4(int sockfd, struct sockaddr *addr,
socklen_t *addrlen, int flags);
DESCRIPTION
L'appel systeme accept() est employe avec les sockets utilisant un
protocole en mode connecte (SOCK_STREAM, SOCK_SEQPACKET). Il extrait la
premiere connexion de la file des connexions en attente de la socket
sockfd a l'ecoute, cree une nouvelle socket et alloue pour cette socket
un nouveau descripteur de fichier qu'il renvoie. La nouvelle socket
n'est pas en etat d'ecoute. La socket originale sockfd n'est pas
modifiee par l'appel systeme.
L'argument sockfd est une socket qui a ete creee avec la fonction
socket(2), attachee a une adresse avec bind(2), et attend des
connexions apres un appel listen(2).
L'argument addr 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 parametre addr depend du domaine dans lequel la communication
s'etablit (consultez socket(2) et la page de manuel correspondant au
protocole). Quand addr vaut NULL, rien n'est rempli ; dans ce cas,
addrlen n'est pas utilise et doit aussi valoir NULL.
addrlen est un parametre-resultat : l'appelant doit l'initialiser de
telle sorte qu'il contienne la taille (en octets) de la structure
pointee par addr, et est renseigne au retour par la longueur reelle (en
octets) de l'adresse remplie.
L'adresse renvoyee est tronquee si le tampon fourni est trop petit ;
dans ce cas, addrlen renverra une valeur superieure a celle fournie
lors de l'appel.
S'il n'y a pas de connexion en attente dans la file, et si la socket
n'est pas marquee comme non-bloquante, accept() se met en attente d'une
connexion. Si la socket est non-bloquante, et qu'aucune connexion n'est
presente dans la file, accept() retourne une erreur EAGAIN ou
EWOULDBLOCK.
Pour etre prevenu de l'arrivee d'une connexion sur une socket, on peut
utiliser select(2) ou poll(2). Un evenement << lecture >> sera delivre
lorsqu'une tentative de connexion aura lieu, et on pourra alors appeler
accept() pour la valider. Autrement, on peut configurer la socket pour
qu'elle envoie un signal SIGIO lorsqu'une activite la concernant se
produit, consultez socket(7) pour plus de details.
Pour certains protocoles necessitant une confirmation explicite, comme
DECNet, accept() peut etre considere comme extrayant simplement la
connexion suivante de la file, sans demander de confirmation. On peut
effectuer la confirmation par une simple lecture ou ecriture sur le
nouveau descripteur, et le rejet en fermant la nouvelle socket. Pour le
moment, seul DECNet se comporte ainsi sous Linux.
Si flags vaut 0, alors accept4() est identique a accept(). Les valeurs
suivantes peuvent etre combinees dans flags par un OU binaire pour
obtenir un comportement different :
SOCK_NONBLOCK Placer l'attribut d'etat de fichier O_NONBLOCK sur le
nouveau descripteur de fichier ouvert. Utiliser cet
attribut economise des appels supplementaires a
fcntl(2) pour obtenir le meme resultat.
SOCK_CLOEXEC Placer l'attribut << close-on-exec >> (FD_CLOEXEC) sur
le nouveau descripteur de fichier. Consultez la
description de l'attribut O_CLOEXEC dans open(2) pour
savoir pourquoi cela peut etre utile.
VALEUR RENVOY'EE
S'ils reussissent, ces appels systeme renvoient un entier positif ou
nul, qui est un descripteur pour la socket acceptee. En cas d'erreur,
ils renvoient -1 et remplissent errno avec le code d'erreur.
Traitement des erreurs
Sous Linux, accept() (et accept4()) renvoie les erreurs reseau deja en
attente sur la socket comme une erreur de l'appel systeme. Ce
comportement differe d'autres implementations des sockets BSD. Pour un
comportement fiable, une application doit detecter les erreurs reseau
definies par le protocole apres le accept() et les traiter comme des
erreurs EAGAIN, en reiterant le mecanisme. Dans le cas de TCP/IP, ces
erreurs sont ENETDOWN, EPROTO, ENOPROTOOPT, EHOSTDOWN, ENONET,
EHOSTUNREACH, EOPNOTSUPP, et ENETUNREACH.
ERREURS
EAGAIN ou EWOULDBLOCK
La socket est marquee comme etant non bloquante et aucune
connexion n'est presente pour etre acceptee. POSIX.1-2001 permet
de renvoyer l'une ou l'autre des erreurs dans ce cas et n'exige
pas que ces constantes aient la meme valeur. Une application
portable devrait donc tester les deux possibilites.
EBADF Le descripteur est invalide.
ECONNABORTED
Une connexion a ete abandonnee.
EFAULT addr n'est pas dans l'espace d'adressage accessible en ecriture.
EINTR L'appel systeme a ete interrompu par l'arrivee d'un signal avant
qu'une connexion valide ne survienne ; consultez signal(7).
EINVAL La socket n'est pas en attente de connexions, ou addrlen est
invalide (par exemple negatif).
EINVAL (accept4()) flags contient une valeur incorrecte.
EMFILE La limite du nombre total de descripteurs de fichier ouverts par
processus a ete atteinte.
ENFILE La limite du nombre total de fichiers ouverts sur le systeme a
ete atteinte.
ENOBUFS, ENOMEM
Pas assez de memoire disponible. En general, cette erreur est
due a la taille limitee du tampon des sockets, et non a la
memoire systeme proprement dite.
ENOTSOCK
Le descripteur n'est pas celui d'une socket.
EOPNOTSUPP
La socket utilisee n'est pas de type SOCK_STREAM.
EPROTO Erreur de protocole.
De plus, la version Linux de accept() peut echouer si :
EPERM Les regles du pare-feu interdisent la connexion.
De plus il peut se produire des erreurs reseau dependant du protocole
de la socket. Certains noyaux Linux peuvent renvoyer d'autres erreurs
comme ENOSR, ESOCKTNOSUPPORT, EPROTONOSUPPORT, ETIMEDOUT. L'erreur
ERESTARTSYS peut etre rencontree durant un suivi dans un debogueur.
VERSIONS
L'appel systeme accept4() est disponible depuis Linux 2.6.28 ; la prise
en charge dans la glibc est disponible depuis la version 2.10.
CONFORMIT'E
accept() : POSIX.1-2001, SVr4, BSD 4.4 (accept() est apparu dans
BSD 4.2).
accept4() est une extension non standard de Linux.
Avec la version Linux de accept(), la nouvelle socket n'herite pas des
attributs comme O_NONBLOCK et O_ASYNC de la socket en ecoute. Ce
comportement est different de l'implementation BSD de reference. Les
programmes portables ne doivent pas s'appuyer sur cette particularite,
et doivent reconfigurer les attributs sur la socket renvoyee par
accept().
NOTES
POSIX.1-2001 ne requiert pas l'inclusion de <sys/types.h>, et cet en-
tete n'est pas necessaire sous Linux. Cependant, il doit etre inclus
sous certaines implementations historiques (BSD), et les applications
portables devraient probablement l'utiliser.
Il n'y a pas necessairement de connexion en attente apres la reception
de SIGIO ou apres que select(2) ou poll(2) indiquent quelque chose a
lire. En effet la connexion peut avoir ete annulee a cause d'une erreur
reseau asynchrone ou par un autre thread avant que accept() ne se
termine. Si cela se produit, l'appel bloquera en attendant une autre
connexion. Pour s'assurer que accept() ne bloquera jamais, la socket
sockfd transmise doit avoir l'attribut O_NONBLOCK (consultez
socket(7)).
Le type socklen_t
Le troisieme argument de accept() etait, a l'origine, declare comme un
int * (ceci dans libc4 et libc5 ainsi que pour beaucoup d'autres
systemes comme BSD 4.x, SunOS 4, SGI). Une proposition de standard
POSIX.1g l'a modifie en size_t * et c'est ce qu'utilise SunOS 5. Les
dernieres propositions POSIX en ont fait un socklen_t *, ce que suivent
la Single Unix Specification et la glibc2. Pour citer Linus Torvalds :
<< Toute bibliotheque sensee doit garder "socklen_t" equivalent a un
int. Toute autre chose invaliderait tout le niveau des sockets BSD.
POSIX l'avait d'abord remplace par un size_t, et je m'en suis plaint
violemment (ainsi que d'autres heureusement, mais de toute evidence,
pas assez). Le remplacement par un size_t est completement stupide car
size_t a rarement la meme taille qu'un int sur les architectures
64 bits par exemple. Et il doit avoir la meme taille qu'un "int" parce
que c'etait l'interface des sockets BSD. Quoi qu'il en soit, les gens
de POSIX ont compris et ont cree un "socklen_t". Ils n'auraient jamais
du y toucher, mais une fois commence, ils ont decide de creer un type
specifique, pour des raisons inavouees (probablement quelqu'un qui ne
veut pas perdre la face en expliquant que le premier travail etait
stupide et ils ont simplement renomme leur bricolage). >>
EXEMPLE
Consultez bind(2).
VOIR AUSSI
bind(2), connect(2), listen(2), select(2), socket(2), socket(7)
COLOPHON
Cette page fait partie de la publication 3.27 du projet man-pages
Linux. Une description du projet et des instructions pour signaler des
anomalies peuvent etre trouvees a l'adresse
<URL:http://www.kernel.org/doc/man-pages/>.
TRADUCTION
Depuis 2010, cette traduction est maintenue a l'aide de l'outil po4a
<URL:http://po4a.alioth.debian.org/> par l'equipe de traduction
francophone au sein du projet perkamon
<URL:http://perkamon.alioth.debian.org/>.
Christophe Blaess <URL:http://www.blaess.fr/christophe/> (1996-2003),
Alain Portal <URL:http://manpagesfr.free.fr/> (2003-2006). Julien
Cristau et l'equipe francophone de traduction de Debian (2006-2009).
Veuillez signaler toute erreur de traduction en ecrivant a
<debian-l10n-french@lists.debian.org> ou par un rapport de bogue sur le
paquet manpages-fr.
Vous pouvez toujours avoir acces a la version anglaise de ce document
en utilisant la commande << man -L C <section> <page_de_man> >>.