ACCEPT(2) | System Calls Manual | ACCEPT(2) |
accept
, accept4
,
paccept
—
#include <sys/socket.h>
int
accept
(int
s, struct sockaddr *
restrict addr, socklen_t
* restrict addrlen);
int
accept4
(int
s, struct sockaddr *
restrict addr, socklen_t
* restrict addrlen, int
flags);
int
paccept
(int
s, struct sockaddr *
restrict addr, socklen_t
* restrict addrlen, const
sigset_t * restrict sigmask,
int flags);
accept
() argument extracts the first connection
request on the queue of pending connections, creates a new socket with the
same properties of s and allocates a new file descriptor
for the socket. If no pending connections are present on the queue, and the
socket is not marked as non-blocking, accept
() blocks
the caller until a connection is present. If the socket is marked non-blocking
and no pending connections are present on the queue,
accept
() returns an error as described below. The
accepted socket may not be used to accept more connections. The original
socket s remains open.
The argument addr is a result parameter that
is filled in with the address of the connecting entity, as known to the
communications layer. The exact format of the addr
parameter is determined by the domain in which the communication is
occurring. The addrlen is a value-result parameter; it
should initially contain the amount of space pointed to by
addr; on return it will contain the actual length (in
bytes) of the address returned. This call is used with connection-based
socket types, currently with SOCK_STREAM
.
It is possible to
select(2) or
poll(2) a socket for the
purposes of doing an accept
() by selecting or
polling it for read.
For certain protocols which require an explicit confirmation, such
as ISO or DATAKIT, accept
() can be thought of as
merely dequeuing the next connection request and not implying confirmation.
Confirmation can be implied by a normal read or write on the new file
descriptor, and rejection can be implied by closing the new socket.
One can obtain user connection request data without confirming the connection by issuing a recvmsg(2) call with an msg_iovlen of 0 and a non-zero msg_controllen, or by issuing a getsockopt(2) request. Similarly, one can provide user connection rejection information by issuing a sendmsg(2) call with providing only the control information, or by calling setsockopt(2).
The accept4
() function is equivalent to
paccept with sigmask NULL
.
The paccept
() function behaves exactly
like accept
(), but it also allows to set the
following flags on the returned file descriptor:
SOCK_CLOEXEC
SOCK_NONBLOCK
SOCK_NOSIGPIPE
EPIPE
instead of raising
SIGPIPE
.It can also temporarily replace the signal mask of the calling
thread if sigmask is a
non-NULL
pointer, then the
paccept
() function shall replace the signal mask of
the caller by the set of signals pointed to by sigmask
before waiting for a connection, and shall restore the signal mask of the
calling thread before returning.
accept
() and paccept
() calls
return -1 on error. If they succeed, they return a non-negative integer that
is a descriptor for the accepted socket.
accept
() implementation makes the new file
descriptor inherit file flags (like O_NONBLOCK
) from
the listening socket. It's a traditional behaviour for BSD derivative systems.
On the other hand, there are implementations which don't do so. Linux is an
example of such implementations. Portable programs should not rely on either
of the behaviours. The
accept4
() function is compatible with the
Linux implementation.
accept
() function will fail if:
EAGAIN
]EBADF
]ECONNABORTED
]EFAULT
]EINTR
]accept
() call has been interrupted by a
signal.EINVAL
]EMFILE
]ENFILE
]ENOTSOCK
]EOPNOTSUPP
]SOCK_STREAM
.accept
() function appeared in
4.2BSD. The accept4
() function
matches Linux semantics and appeared in NetBSD 8.0.
The paccept
() function is inspired from Linux and
appeared in NetBSD 6.0.
February 8, 2017 | NetBSD 9.2 |