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