Provided by: manpages-fr-dev_3.27fr1.4-1_all bug

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