xref: /netbsd/lib/libc/sys/accept.2 (revision bf9ec67e)
1.\"	$NetBSD: accept.2,v 1.20 2002/02/08 01:28:16 ross Exp $
2.\"
3.\" Copyright (c) 1983, 1990, 1991, 1993
4.\"	The Regents of the University of California.  All rights reserved.
5.\"
6.\" Redistribution and use in source and binary forms, with or without
7.\" modification, are permitted provided that the following conditions
8.\" are met:
9.\" 1. Redistributions of source code must retain the above copyright
10.\"    notice, this list of conditions and the following disclaimer.
11.\" 2. Redistributions in binary form must reproduce the above copyright
12.\"    notice, this list of conditions and the following disclaimer in the
13.\"    documentation and/or other materials provided with the distribution.
14.\" 3. All advertising materials mentioning features or use of this software
15.\"    must display the following acknowledgement:
16.\"	This product includes software developed by the University of
17.\"	California, Berkeley and its contributors.
18.\" 4. Neither the name of the University nor the names of its contributors
19.\"    may be used to endorse or promote products derived from this software
20.\"    without specific prior written permission.
21.\"
22.\" THIS SOFTWARE IS PROVIDED BY THE REGENTS AND CONTRIBUTORS ``AS IS'' AND
23.\" ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
24.\" IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
25.\" ARE DISCLAIMED.  IN NO EVENT SHALL THE REGENTS OR CONTRIBUTORS BE LIABLE
26.\" FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL
27.\" DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS
28.\" OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
29.\" HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT
30.\" LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY
31.\" OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF
32.\" SUCH DAMAGE.
33.\"
34.\"     @(#)accept.2	8.2 (Berkeley) 12/11/93
35.\"
36.Dd October 22, 2001
37.Dt ACCEPT 2
38.Os
39.Sh NAME
40.Nm accept
41.Nd accept a connection on a socket
42.Sh LIBRARY
43.Lb libc
44.Sh SYNOPSIS
45.Fd #include \*[Lt]sys/socket.h\*[Gt]
46.Ft int
47.Fn accept "int s" "struct sockaddr * restrict addr" "socklen_t * restrict addrlen"
48.Sh DESCRIPTION
49The argument
50.Fa s
51is a socket that has been created with
52.Xr socket 2 ,
53bound to an address with
54.Xr bind 2 ,
55and is listening for connections after a
56.Xr listen 2 .
57The
58.Fn accept
59argument
60extracts the first connection request
61on the queue of pending connections, creates
62a new socket with the same properties of
63.Fa s
64and allocates a new file descriptor
65for the socket.  If no pending connections are
66present on the queue, and the socket is not marked
67as non-blocking,
68.Fn accept
69blocks the caller until a connection is present.
70If the socket is marked non-blocking and no pending
71connections are present on the queue,
72.Fn accept
73returns an error as described below.
74The accepted socket
75may not be used
76to accept more connections.  The original socket
77.Fa s
78remains open.
79.Pp
80The argument
81.Fa addr
82is a result parameter that is filled in with
83the address of the connecting entity,
84as known to the communications layer.
85The exact format of the
86.Fa addr
87parameter is determined by the domain in which the communication
88is occurring.
89The
90.Fa addrlen
91is a value-result parameter; it should initially contain the
92amount of space pointed to by
93.Fa addr ;
94on return it will contain the actual length (in bytes) of the
95address returned.
96This call
97is used with connection-based socket types, currently with
98.Dv SOCK_STREAM .
99.Pp
100It is possible to
101.Xr select 2
102or
103.Xr poll 2
104a socket for the purposes of doing an
105.Fn accept
106by selecting or polling it for read.
107.Pp
108For certain protocols which require an explicit confirmation,
109such as
110.Tn ISO
111or
112.Tn DATAKIT ,
113.Fn accept
114can be thought of
115as merely dequeuing the next connection
116request and not implying confirmation.
117Confirmation can be implied by a normal read or write on the new
118file descriptor, and rejection can be implied by closing the
119new socket.
120.Pp
121One can obtain user connection request data without confirming
122the connection by issuing a
123.Xr recvmsg 2
124call with an
125.Fa msg_iovlen
126of 0 and a non-zero
127.Fa msg_controllen ,
128or by issuing a
129.Xr getsockopt 2
130request.
131Similarly, one can provide user connection rejection information
132by issuing a
133.Xr sendmsg 2
134call with providing only the control information,
135or by calling
136.Xr setsockopt 2 .
137.Sh RETURN VALUES
138The call returns \-1 on error.  If it succeeds, it returns a non-negative
139integer that is a descriptor for the accepted socket.
140.Sh ERRORS
141The
142.Fn accept
143will fail if:
144.Bl -tag -width Er
145.It Bq Er EBADF
146The descriptor is invalid.
147.It Bq Er EINVAL
148The socket has not been set up to accept connections (using
149.Xr bind 2
150and
151.Xr listen 2 ) .
152.It Bq Er ENOTSOCK
153The descriptor references a file, not a socket.
154.It Bq Er EOPNOTSUPP
155The referenced socket is not of type
156.Dv SOCK_STREAM .
157.It Bq Er EFAULT
158The
159.Fa addr
160parameter is not in a writable part of the
161user address space.
162.It Bq Er EAGAIN
163The socket is marked non-blocking and no connections
164are present to be accepted.
165.It Bq Er EMFILE
166The per-process descriptor table is full.
167.It Bq Er ENFILE
168The system file table is full.
169.It Bq Er ECONNABORTED
170A connection has been aborted.
171.El
172.Sh SEE ALSO
173.Xr bind 2 ,
174.Xr connect 2 ,
175.Xr listen 2 ,
176.Xr poll 2 ,
177.Xr select 2 ,
178.Xr socket 2
179.Sh HISTORY
180The
181.Fn accept
182function appeared in
183.Bx 4.2 .
184