1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
|
.\" 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
.TH ACCEPT 2 "8 Avril 1997" BSD "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 *" addr ", int *" addrlen );
.SH DESCRIPTION
.B accept
est utilise generalement avec des processus serveurs orientes\-connexion.
L'argument
.I sock
est une socket qui a ete creee avec la fonction
.BR socket (2).
On lui a affecte une adresse avec
.BR bind (2).
Enfin on a indique au systeme,
avec
.BR listen (2)
qu'elle
desirait recevoir des connexions entrantes.
L'appel systeme
.B accept
extrait la premiere connexion de la file des connexions en attente,
cree une nouvelle socket avec les memes proprietes 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 presente dans la file,
.B accept
retourne une erreur decrite ci-dessous.
Une socket acceptee ne peut
pas etre utilisee pour accepter de nouvelles connexions. La socket
originale
.I sock
reste ouverte.
L'argument
.I addr
est un parametre resultat qui est renseigne avec l'adresse de l'entite
se connectant, telle qu'elle est connue par la couche de communication.
Le format exact du parametre
.I addr
est fonction du domaine dans lequel la communication s'etablit. Le
parametre-resultat
.I addrlen
est renseigne avec la longueur (en octets) de l'adresse retournee.
Ce parametre doit initialement contenir la longueur du parametre
.I addr.
Cet appel systeme est utilise avec les sockets utilisant un protocole
en mode connecte, generalement du type
.BR SOCK_STREAM .
Lorsque l'on desire accepter des connexions sur plusieurs sockets
simultanement, il est important de ne pas rester bloque en
attente avec l'appel
.B accept
sur une seule d'entre elles.
Il est alors possible d'utiliser l'appel-systeme
.BR select (2)
sur l'ensemble des sockets pour determiner la disponibilite
des donnees a lire, et d'effectuer ensuite l'appel
.B accept
sur celles qui ont effectivement recu des demandes de connexion.
Pour certain protocoles necessitant une confirmation explicite,
comme
.B ISO
ou
.BR DATAKIT ,
.B accept
peut etre considere comme extrayant simplement la connexion suivante de
la file, sans demander de confirmation. Cette confirmation peut etre
effectuee par une simple lecture ou ecriture sur le nouveau descripteur
de fichier, et un rejet peut etre effectue en fermant simplement la
nouvelle socket.
On peut obtenir les donnees utilisateur d'une connexion sans
confirmation, en effectuant un appel-systeme
.BR recvmsg (2)
avec un
.I msg_iovlen
valant zero, et un
.IR msg_controllen
non nul, ou en effectuant une demande
.BR getsockopt (2).
De meme on peut fournir des informations sur un rejet de connexion en
utilisant un appel
.BR sendmsg (2)
en fournissant uniquement les donnees de controle,
ou en appelant
.BR setsockopt (2).
.SH "VALEUR RENVOYEE"
.BR accept
renvoie \-1 en cas d'erreur. S'il reussit il renvoie
un entier non-negatif, 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 reference n'est pas de type
.BR SOCK_STREAM .
.TP
.B EFAULT
.I addr
pointe en-dehors de l'espace d'adresse accessible.
.TP
.B EWOULDBLOCK
La socket est non-bloquante et aucune connexion n'est
presente dans la file.
.SH EXEMPLE
Un scenario typique de mise en oeuvre de serveur oriente
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 pere */
close (nouvelle);
/* Attendre la connexion suivante */
continue;
}
perror ("fork");
exit (1);
}
.fi
.SH "CONFORMITE"
SVr4, BSD 4.4.
La fonction
.B accept
est apparue dans BSD 4.2. SVr4 fournit une condition d'erreur
supplementaire EOPNOTSUPP.
.SH "VOIR AUSSI"
.BR bind "(2), " connect "(2), " listen "(2), " select "(2), " socket (2)
|
