accept

ACCEPT(2)                  Manuel du programmeur Linux                 ACCEPT(2)



NOM
       accept, accept4 - 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 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 (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 utilisé et
       doit aussi valoir NULL.

       addrlen est un paramètre-résultat : l'appelant doit l'initialiser de
       telle sorte qu'il contienne la taille (en octets) de la structure pointée
       par addr, et est renseigné au retour par la longueur réelle (en octets)
       de l'adresse remplie.

       L'adresse renvoyée est tronquée si le tampon fourni est trop petit ; dans
       ce cas, addrlen renverra une valeur supérieure à 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 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 ou
       EWOULDBLOCK.

       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, consultez 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.

       Si flags vaut 0, alors accept4() est identique à accept(). Les valeurs
       suivantes peuvent être combinées dans flags par un OU binaire pour
       obtenir un comportement différent :

       SOCK_NONBLOCK   Placer l'attribut d'état de fichier O_NONBLOCK sur le
                       nouveau descripteur de fichier ouvert. Utiliser cet
                       attribut économise des appels supplémentaires à fcntl(2)
                       pour obtenir le même résultat.

       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 être utile.

VALEUR RENVOYÉE
       S'ils réussissent, ces appels système renvoient un entier positif ou nul,
       qui est un descripteur pour la socket acceptée. 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 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
       EAGAIN ou EWOULDBLOCK
              La socket est marquée comme étant non bloquante et aucune
              connexion n'est présente pour être acceptée. 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 même valeur. Une application
              portable devrait donc tester les deux possibilités.

       EBADF  Le descripteur est invalide.

       ECONNABORTED
              Une connexion a été abandonnée.

       EFAULT addr n'est pas dans l'espace d'adressage accessible en écriture.

       EINTR  L'appel système a été interrompu par l'arrivée 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 négatif).

       EINVAL (accept4()) flags contient une valeur incorrecte.

       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.

       ENOBUFS, ENOMEM
              Pas assez de mémoire disponible. En général, cette erreur est due
              à la taille limitée du tampon des sockets, et non à la mémoire
              système proprement dite.

       ENOTSOCK
              Le descripteur n'est pas celui d'une socket.

       EOPNOTSUPP
              La socket utilisée n'est pas de type SOCK_STREAM.

       EPROTO Erreur de protocole.

       De plus, 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.

VERSIONS
       L'appel système accept4() est disponible depuis Linux 2.6.28 ; la prise
       en charge dans la glibc est disponible depuis la version 2.10.

CONFORMITÉ
       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'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 (consultez 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
       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.70 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
       Depuis 2010, cette traduction est maintenue à l'aide de l'outil po4a
       <http://po4a.alioth.debian.org/> par l'équipe de traduction francophone
       au sein du projet perkamon <http://perkamon.alioth.debian.org/>.

       Christophe Blaess <http://www.blaess.fr/christophe/> (1996-2003), Alain
       Portal <http://manpagesfr.free.fr/> (2003-2006).  Julien Cristau et
       l'équipe francophone de traduction de Debian (2006-2009).

       Veuillez signaler toute erreur de traduction en écrivant à
       <perkamon-fr@traduc.org>.

       Vous pouvez toujours avoir accès à la version anglaise de ce document en
       utilisant la commande « LC_ALL=C man <section> <page_de_man> ».



Linux                           10 septembre 2010                      ACCEPT(2)