.\" Copyright (c) 1983, 1990, 1991 The Regents of the University of California.
.\" All rights reserved.
.\"
.\" Redistribution and use in source and binary forms, with or without
.\" modification, are permitted provided that the following conditions
.\" are met:
.\" 1. Redistributions of source code must retain the above copyright
.\"    notice, this list of conditions and the following disclaimer.
.\" 2. Redistributions in binary form must reproduce the above copyright
.\"    notice, this list of conditions and the following disclaimer in the
.\"    documentation and/or other materials provided with the distribution.
.\" 3. All advertising materials mentioning features or use of this software
.\"    must display the following acknowledgement:
.\"	This product includes software developed by the University of
.\"	California, Berkeley and its contributors.
.\" 4. Neither the name of the University nor the names of its contributors
.\"    may be used to endorse or promote products derived from this software
.\"    without specific prior written permission.
.\"
.\" THIS SOFTWARE IS PROVIDED BY THE REGENTS AND CONTRIBUTORS ``AS IS'' AND
.\" ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
.\" IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
.\" ARE DISCLAIMED.  IN NO EVENT SHALL THE REGENTS OR CONTRIBUTORS BE LIABLE
.\" FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL
.\" DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS
.\" OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
.\" HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT
.\" LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY
.\" OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF
.\" SUCH DAMAGE.
.\"
.\"     @(#)accept.2	6.6 (Berkeley) 4/29/91
.\"
.\" Modified Sat Jul 24 16:42:42 1993 by Rik Faith (faith@cs.unc.edu)
.\"
.\" Traduction 9/10/1996 par Christophe Blaess (ccb@club-internet.fr)
.\"
.\" Correction le 15/12/96 suite a une remarque de <Yves.Arrouye@marin.fdn.fr>
.\" Mise a Jour 8/04/97
.\" Mise  Jour 18/05/99 - LDP-man-pages 1.23
.TH ACCEPT 2 "18 Mai 1999" Linux "Manuel du programmeur Linux"
.SH NOM
accept \- Accepter une connexion sur une socket.
.SH SYNOPSIS
.B #include <sys/types.h>
.br
.B #include <sys/socket.h>
.br
.BI "int accept(int " sock ", struct sockaddr *" adresse ", socklent_t *" longueur );
.SH DESCRIPTION

.B accept
est utilis gnralement avec des processus serveurs orients\-connexion.

L'argument
.I sock
est une socket qui a t cre avec la fonction
.BR socket (2).
On lui a affect une adresse avec
.BR bind (2).
Enfin on a indiqu au systme,
avec
.BR listen (2)
qu'elle
dsirait recevoir des connexions entrantes.

L'appel systme
.B accept
extrait la premire connexion de la file des connexions en attente,
cre une nouvelle socket avec les mmes proprits que
.I sock
et alloue un nouveau descripteur de fichier pour cette socket.

S'il n'y a pas de connexion en attente dans la file, et si la socket
est bloquante,
.B accept
se met en attente d'une connexion. Si la socket est 
non-bloquante, et qu'aucune connexion n'est prsente dans la file,
.B accept
retourne une erreur dcrite ci-dessous. 

Une socket accepte ne peut
pas tre utilise pour accepter de nouvelles connexions. La socket
originale
.I sock
reste ouverte.

L'argument
.I adresse
est un paramtre rsultat qui est renseign avec l'adresse de l'entit
se connectant, telle qu'elle est connue par la couche de communication.
Le format exact du paramtre
.I adresse
est fonction du domaine dans lequel la communication s'tablit. Le
paramtre-resultat
.I longueur
est renseign avec la longueur (en octets) de l'adresse retourne.
Ce paramtre doit initialement contenir la longueur du paramtre
.I adresse.

Cet appel systme est utilis avec les sockets utilisant un protocole
en mode connect, gnralement du type
.BR SOCK_STREAM . 

Lorsque l'on dsire accepter des connexions sur plusieurs sockets
simultanment, il est important de ne pas rester bloqu en
attente avec l'appel
.B accept
sur une seule d'entre elles.
Il est alors possible d'utiliser l'appel-systme
.BR select (2)
sur l'ensemble des sockets pour dterminer la disponibilit
des donnes  lire, et d'effectuer ensuite l'appel
.B accept
sur celles qui ont effectivement reu des demandes de connexion.


Pour certains protocoles ncessitant une confirmation explicite,
comme
.B ISO
ou
.BR DATAKIT ,
.B accept
peut tre considr comme extrayant simplement la connexion suivante de
la file, sans demander de confirmation. Cette confirmation peut tre
effectue par une simple lecture ou criture sur le nouveau descripteur
de fichier, et un rejet peut tre effectu en fermant simplement la 
nouvelle socket.

On peut obtenir les donnes utilisateur d'une connexion sans
confirmation, en effectuant un appel-systme
.BR recvmsg (2)
avec un
.I msg_iovlen
valant zro, et un
.IR msg_controllen
non nul, ou en effectuant une demande
.BR getsockopt (2).

De mme on peut fournir des informations sur un rejet de connexion en
utilisant un appel
.BR sendmsg (2)
en fournissant uniquement les donnes de contrle,
ou en appelant
.BR setsockopt (2).
.SH "VALEUR RENVOYE"
.BR accept
renvoie \-1 en cas d'erreur. S'il russit il renvoie
un entier non-ngatif, constituant un descripteur pour la nouvelle
socket.
.SH ERREURS
.TP 0.8i
.B EBADF
.I sock
est un descripteur invalide.
.TP
.B ENOTSOCK
.I sock
est un descripteur de fichier, pas de socket.
.TP
.B EOPNOTSUPP
La socket de rfrence n'est pas de type
.BR SOCK_STREAM . 
.TP
.B EFAULT
.I adresse
pointe en-dehors de l'espace d'adressage accessible.
.TP
.B EWOULDBLOCK
La socket est non-bloquante et aucune connexion n'est
prsente dans la file.
.SH EXEMPLE

Un scnario typique de mise en oeuvre de serveur orient
connexion est le suivant :

.nf

int  pnum;
int  sock;
int  nouvelle;

sock  = socket (famille, type, 0);
if (sock < 0) {
    perror ("socket");
    exit (1);
}
if (bind (sock, & mon_adresse, longueur_adresse) < 0) {
    perror ("bind");
    exit (1);
}
if (listen (sock, 5) < 0) {
    perror ("listen");
    exit (1);
}

while (1) {

    nouvelle = accept (sock, & adresse_client, & lg_adresse_client);
    if (nouvelle < 0) {
        perror ("accept");
        exit (1);
    }

    if ((pnum = fork ()) == 0) {
        /* Processus fils */
        close (sock);
        Traiter_le_client (nouvelle);
        exit (0);
    }

    if (pnum > 0) {

        /* Processus pre */
        close (nouvelle);
        /* Attendre la connexion suivante */
        continue;
    }

    perror ("fork");
    exit (1);
}
.fi
.SH "CONFORMIT"
SVr4, BSD 4.4.
La fonction
.B accept
est apparue dans BSD 4.2. IRIX fournit des conditions d'erreur
supplmentaires EMFILE et ENFILE.
Solaris documente les erreurs supplmentaires EINTR, ENODEV, ENOMEM,
ENOSR et EPROTO.
.SH NOTE
Le troisime argument de
.B accept
tait,  l'origine, dclar comme un `int *' (et c'est le cas dans libc4 et libc5
ainsi que pour beaucoup d'autres systmes 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 dernires propositions POSIX en ont fait un
`socklen_t *', ce que suivent les spcifications Single Unix, et la glibc2.
Pour citer Linus Torvalds: `\fBToute\fP bibliothque sense \fBdoit\fP 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 compltement inutile car size_t  exactement
la mme taille qu'un int sur les architectures 64 bits par exemple. Et il \fBa\fP
la mme taille qu'un "int" parce que c'tait ainsi qu'taient dfinies les sockets BSD. 
Finalement, 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 dcid de crer un type spcifique,
pour des raisons encore inavoues (il y a 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).
.SH "VOIR AUSSI"
.BR bind "(2), " connect "(2), " listen "(2), " select "(2), " socket (2)

.SH TRADUCTION
Christophe Blaess, 1997.