1.\" $NetBSD: accept.2,v 1.36 2025/04/02 19:30:37 uwe 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. Neither the name of the University nor the names of its contributors 15.\" may be used to endorse or promote products derived from this software 16.\" without specific prior written permission. 17.\" 18.\" THIS SOFTWARE IS PROVIDED BY THE REGENTS AND CONTRIBUTORS ``AS IS'' AND 19.\" ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE 20.\" IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE 21.\" ARE DISCLAIMED. IN NO EVENT SHALL THE REGENTS OR CONTRIBUTORS BE LIABLE 22.\" FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL 23.\" DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS 24.\" OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) 25.\" HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT 26.\" LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY 27.\" OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF 28.\" SUCH DAMAGE. 29.\" 30.\" @(#)accept.2 8.2 (Berkeley) 12/11/93 31.\" 32.Dd October 27, 2019 33.Dt ACCEPT 2 34.Os 35.Sh NAME 36.Nm accept , 37.Nm accept4 , 38.Nm paccept 39.Nd accept a connection on a socket 40.Sh LIBRARY 41.Lb libc 42.Sh SYNOPSIS 43.In sys/socket.h 44.Ft int 45.Fn accept "int s" "struct sockaddr * restrict addr" "socklen_t * restrict addrlen" 46.Ft int 47.Fn accept4 "int s" "struct sockaddr * restrict addr" "socklen_t * restrict addrlen" "int flags" 48.Ft int 49.Fn paccept "int s" "struct sockaddr * restrict addr" "socklen_t * restrict addrlen" "const sigset_t * restrict sigmask" "int flags" 50.Sh DESCRIPTION 51The argument 52.Fa s 53is a socket that has been created with 54.Xr socket 2 , 55bound to an address with 56.Xr bind 2 , 57and is listening for connections after a 58.Xr listen 2 . 59The 60.Fn accept 61function 62extracts the first connection request on the queue of pending 63connections, creates a new socket with the same properties of 64.Fa s 65and allocates a new file descriptor 66for the socket. 67If no pending connections are 68present on the queue, and the socket is not marked 69as non-blocking, 70.Fn accept 71blocks the caller until a connection is present. 72If the socket is marked non-blocking and no pending 73connections are present on the queue, 74.Fn accept 75returns an error as described below. 76The accepted socket 77may not be used 78to accept more connections. 79The original socket 80.Fa s 81remains open. 82.Pp 83The argument 84.Fa addr 85is a result parameter that is filled in with 86the address of the connecting entity, 87as known to the communications layer. 88The exact format of the 89.Fa addr 90parameter is determined by the domain in which the communication 91is occurring. 92The 93.Fa addrlen 94is a value-result parameter; it should initially contain the 95amount of space pointed to by 96.Fa addr ; 97on return it will contain the actual length (in bytes) of the 98address returned. 99This call 100is used with connection-based socket types, currently with 101.Dv SOCK_STREAM . 102.Pp 103It is possible to 104.Xr select 2 105or 106.Xr poll 2 107a socket for the purposes of doing an 108.Fn accept 109by selecting or polling it for read. 110.Pp 111For certain protocols which require an explicit confirmation, 112such as 113.Tn ISO 114or 115.Tn DATAKIT , 116.Fn accept 117can be thought of 118as merely dequeuing the next connection 119request and not implying confirmation. 120Confirmation can be implied by a normal read or write on the new 121file descriptor, and rejection can be implied by closing the 122new socket. 123.Pp 124One can obtain user connection request data without confirming 125the connection by issuing a 126.Xr recvmsg 2 127call with an 128.Fa msg_iovlen 129of 0 and a non-zero 130.Fa msg_controllen , 131or by issuing a 132.Xr getsockopt 2 133request. 134Similarly, one can provide user connection rejection information 135by issuing a 136.Xr sendmsg 2 137call with providing only the control information, 138or by calling 139.Xr setsockopt 2 . 140.Pp 141The socket returned by 142.Fn accept 143inherits the 144.Dv O_NONBLOCK 145setting of 146.Fa s . 147This is a nonstandard guarantee; portable applications should not rely 148it. 149.Pp 150The 151.Fn accept4 152function behaves exactly like 153.Fn accept , 154but the socket it returns does not inherit the 155.Dv O_NONBLOCK 156flag of 157.Fa s ; 158instead, it accepts the following flags: 159.Fa flags 160on the returned file descriptor: 161.Bl -column -offset indent ".Dv SOCK_NOSIGPIPE" 162.It Dv SOCK_CLOEXEC Ta Set the close-on-exec property. 163.It Dv SOCK_NONBLOCK Ta Sets non-blocking I/O. 164.It Dv SOCK_NOSIGPIPE Ta Xo 165Return 166.Er EPIPE 167instead of raising 168.Dv SIGPIPE . 169.Xc 170.El 171.Pp 172The 173.Fn paccept 174function behaves exactly like 175.Fn accept4 , 176but it also accepts a signal mask 177.Fa sigmask . 178If 179.Fa sigmask 180is 181.Pf non- Dv NULL , 182.Fn paccept 183replaces the signal mask of the calling thread by it while 184.Fn paccept 185is waiting for a connection, and then restores the signal mask on 186return. 187.Pp 188The 189.Fn accept4 190function is equivalent to 191.Fn paccept 192with 193.Dv NULL 194as the argument for 195.Fa sigmask . 196.Sh RETURN VALUES 197The 198.Fn accept , 199.Fn accept4 , 200and 201.Fn paccept 202functions return \-1 and set 203.Xr errno 2 204on error. 205If they succeed, they return a non-negative 206integer that is a descriptor for the accepted socket. 207.Sh COMPATIBILITY 208The 209.Fn accept 210implementation makes the new file descriptor inherit file flags 211.Pq like Dv O_NONBLOCK 212from the listening socket. 213It's a traditional behaviour for 214.Bx 215derivative systems. 216On the other hand, there are implementations which don't do so. 217Linux is an example of such implementations. 218Portable programs should not rely on either of the behaviours. 219.Pp 220The 221.Fn accept 222and 223.Fn accept4 224functions conform to 225.St -p1003.1-2024 . 226.Pp 227The non-standard 228.Fn paccept 229function is compatible with the Linux implementation. 230.Sh ERRORS 231The 232.Fn accept 233function will fail if: 234.Bl -tag -width Er 235.It Bq Er EAGAIN 236The socket is marked non-blocking and no connections 237are present to be accepted. 238.It Bq Er EBADF 239The descriptor is invalid. 240.It Bq Er ECONNABORTED 241A connection has been aborted. 242.It Bq Er EFAULT 243The 244.Fa addr 245parameter is not in a writable part of the 246user address space. 247.It Bq Er EINTR 248The 249.Fn accept 250call has been interrupted by a signal. 251.It Bq Er EINVAL 252The socket has not been set up to accept connections 253.Po 254using 255.Xr bind 2 256and 257.Xr listen 2 258.Pc . 259.It Bq Er EMFILE 260The per-process descriptor table is full. 261.It Bq Er ENFILE 262The system file table is full. 263.It Bq Er ENOTSOCK 264The descriptor references a file, not a socket. 265.It Bq Er EOPNOTSUPP 266The referenced socket is not of type 267.Dv SOCK_STREAM . 268.El 269.Sh SEE ALSO 270.Xr bind 2 , 271.Xr connect 2 , 272.Xr listen 2 , 273.Xr poll 2 , 274.Xr select 2 , 275.Xr socket 2 276.Sh HISTORY 277The 278.Fn accept 279function appeared in 280.Bx 4.2 . 281The 282.Fn paccept 283function appeared in 284.Nx 6.0 . 285The 286.Fn accept4 287function appeared in 288.Nx 8.0 . 289