NAME
accept,
accept4,
paccept
—
accept a connection on a socket
LIBRARY
Standard C Library (libc, -lc)
SYNOPSIS
#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);
DESCRIPTION
The argument
s is a socket that has been created with
socket(2), bound to an address
with
bind(2), and is listening for
connections after a
listen(2).
The
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
- Set the close on exec property.
-
-
SOCK_NONBLOCK
- Sets non-blocking I/O.
-
-
SOCK_NOSIGPIPE
- Return
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.
RETURN VALUES
The
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.
COMPATIBILITY
The
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.
ERRORS
The
accept() function will fail if:
-
-
- [
EAGAIN
]
- The socket is marked non-blocking and no connections are
present to be accepted.
-
-
- [
EBADF
]
- The descriptor is invalid.
-
-
- [
ECONNABORTED
]
- A connection has been aborted.
-
-
- [
EFAULT
]
- The addr parameter is not in a
writable part of the user address space.
-
-
- [
EINTR
]
- The accept() call has been interrupted by
a signal.
-
-
- [
EINVAL
]
- The socket has not been set up to accept connections (using
bind(2) and
listen(2)).
-
-
- [
EMFILE
]
- The per-process descriptor table is full.
-
-
- [
ENFILE
]
- The system file table is full.
-
-
- [
ENOTSOCK
]
- The descriptor references a file, not a socket.
-
-
- [
EOPNOTSUPP
]
- The referenced socket is not of type
SOCK_STREAM
.
SEE ALSO
bind(2),
connect(2),
listen(2),
poll(2),
select(2),
socket(2)
HISTORY
The
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.