Provided by:
manpages-fr-dev_3.07.1-1_all 
NOM
accept - Accepter une connexion sur une socket
SYNOPSIS
#include <sys/types.h> /* Voir NOTES */
#include <sys/socket.h>
int accept(int sockfd, struct sockaddr *addr, socklen_t *addrlen);
DESCRIPTION
L’appel système accept() est employé avec les sockets utilisant un
protocole en mode connecté (SOCK_STREAM, SOCK_SEQPACKET). Il extrait la
première connexion de la file des connexions en attente de la socket
sockfd à l’écoute, crée une nouvelle socket et alloue pour cette socket
un nouveau descripteur de fichier qu’il renvoie. La nouvelle socket
n’est pas en état d’écoute. La socket originale sockfd n’est pas
modifiée par l’appel système.
L’argument sockfd est une socket qui a été créée avec la fonction
socket(2), attachée à une adresse avec bind(2), et attend des
connexions après 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 paramètre addr dépend du domaine dans lequel la communication
s’établit (voir socket(2) et la page de manuel correspondant au
protocole). L’argument addrlen est un paramètre-résultat : il doit
contenir initialement la taille de la structure pointée par addr, et
est renseigné au retour par la longueur réelle (en octets) de l’adresse
remplie. Quand addr 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, accept() se met en attente d’une
connexion. Si la socket est non‐bloquante, et qu’aucune connexion n’est
présente dans la file, accept() retourne une erreur EAGAIN.
Pour être prévenu de l’arrivée d’une connexion sur une socket on peut
utiliser select(2) ou poll(2). Un événement « lecture » sera délivré
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 activité la concernant se
produit, voir socket(7) pour plus de détails.
Pour certains protocoles nécessitant une confirmation explicite, comme
DECNet, accept() 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.
VALEUR RENVOYÉE
S’il réussit, accept() renvoie un entier positif ou nul, qui est un
descripteur pour la socket acceptée. En cas d’erreur, il renvoie -1 et
remplit errno avec le code d’erreur.
Traitement des erreurs
Sous Linux, accept() 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 accept() et les traiter comme des erreurs EAGAIN, en
réitérant le mécanisme. Dans le cas de TCP/IP, ces erreurs sont
ENETDOWN, EPROTO, ENOPROTOOPT, EHOSTDOWN, ENONET, EHOSTUNREACH,
EOPNOTSUPP, et ENETUNREACH.
ERREURS
accept() doit échouer si :
EAGAIN ou EWOULDBLOCK
La socket est non‐bloquante et aucune connexion n’est présente
dans la file.
EBADF Le descripteur est invalide.
ECONNABORTED
Une connexion a été abandonnée.
EINTR L’appel système a été interrompu par l’arrivée d’un signal avant
qu’une connexion valide ne survienne ; voir signal(7).
EINVAL La socket n’est pas en attente de connexions, ou addrlen est
invalide (par exemple négatif).
EMFILE La limite du nombre total de descripteurs de fichier ouverts par
processus a été atteinte.
ENFILE La limite du nombre total de fichiers ouverts sur le système a
été atteinte.
ENOTSOCK
Le descripteur n’est pas celui d’une socket.
EOPNOTSUPP
La socket de référence n’est pas de type SOCK_STREAM.
accept() peut échouer si :
EFAULT addr n’est pas dans l’espace d’adressage accessible en écriture.
ENOBUFS, ENOMEM
Par assez de mémoire disponible. En général, cette erreur due à
la taille limitée du tampon des sockets, et pas à la mémoire
système proprement dite.
EPROTO Erreur de protocole.
La version Linux de accept() peut échouer si :
EPERM Les règles du pare-feu interdisent la connexion.
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 ENOSR, ESOCKTNOSUPPORT, EPROTONOSUPPORT, ETIMEDOUT. L’erreur
ERESTARTSYS peut être rencontrée durant un suivi dans un débogueur.
CONFORMITÉ
SVr4, BSD 4.4 (la fonction accept() est apparue dans BSD 4.2),
POSIX.1-2001.
Avec la version Linux de accept(), la nouvelle socket n’hérite pas des
attributs comme O_NONBLOCK et O_ASYNC de la socket en écoute. Ce
comportement est différent de l’implémentation BSD de référence. Les
programmes portables ne doivent pas s’appuyer sur cette particularité,
et doivent reconfigurer les attributs sur la socket renvoyée par
accept().
NOTES
POSIX.1-2001 ne requiert pas l’inclusion de <sys/types.h>, et cet
en‐tête n’est pas nécessaire sous Linux. Cependant, il doit être inclus
sous certaines implémentations historiques (BSD), et les applications
portables devraient probablement l’utiliser.
Il n’y a pas nécessairement de connexion en attente après la réception
de SIGIO ou après que select(2) ou poll(2) 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 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 (voir socket(7)).
Le type socklen_t
Le troisième argument de accept() était, à l’origine, déclaré comme un
int * (ceci dans libc4 et libc5 ainsi que pour beaucoup d’autres
systèmes comme BSD 4.x, SunOS 4, SGI). Une proposition de standard
POSIX.1g l’a modifié en size_t * et c’est ce qu’utilise SunOS 5. Les
dernières propositions POSIX en ont fait un socklen_t *, ce que suivent
la Single Unix Specification et la glibc2. Pour citer Linus Torvalds :
« Toute 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 de toute évidence,
pas assez). Le remplacement par un size_t est complètement stupide car
size_t a rarement la même taille qu’un int sur les architectures
64 bits par exemple. Et il doit avoir la même taille qu’un "int" parce
que c’était l’interface des sockets BSD. Quoi qu’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). »
EXEMPLE
Voir bind(2).
VOIR AUSSI
bind(2), connect(2), listen(2), select(2), socket(2)
COLOPHON
Cette page fait partie de la publication 3.07 du projet man-pages
Linux. Une description du projet et des instructions pour signaler des
anomalies peuvent être trouvées à l’adresse
http://www.kernel.org/doc/man-pages/.
TRADUCTION
Cette page de manuel a été traduite et mise à jour par Christophe
Blaess <http://www.blaess.fr/christophe/> entre 1996 et 2003, puis par
Alain Portal <aportal AT univ-montp2 DOT fr> jusqu’en 2006, et mise à
disposition sur http://manpagesfr.free.fr/.
Les mises à jour et corrections de la version présente dans Debian sont
directement gérées par Julien Cristau <jcristau@debian.org> et l’équipe
francophone de traduction de Debian.
Veuillez signaler toute erreur de traduction en écrivant à
<debian-l10n-french@lists.debian.org> ou par un rapport de bogue sur le
paquet manpages-fr.
Vous pouvez toujours avoir accès à la version anglaise de ce document
en utilisant la commande « man -L C <section> <page_de_man> ».