accept - accept a connection on a socket
int accept(int s, struct sockaddr *addr, int *addrlen
The argument s is a socket that has been created with
socket(2), bound to an address with bind(2), and is listen-
ing for connections after a listen(2). The accept function
extracts the first connection request on the queue of pend-
ing connections, creates a new socket with the same proper-
ties 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 connec-
tions. 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 parame-
ter 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) a socket for the purposes of
doing an accept by selecting it for read.
For certain protocols which require an explicit confirma-
tion, such as ISO or DATAKIT, accept can be thought of as
merely dequeuing the next connection request and not imply-
ing 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 confirm-
ing 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 cal-
The call returns -1 on error. If it succeeds, it returns a
non-negative integer that is a descriptor for the accepted
The BSD man page documents five possible error returns.
The descriptor is invalid.
The descriptor references a file, not a socket.
The referenced socket is not of type SOCK_STREAM.
The addr parameter is not in a writable part of the
user address space.
The socket is marked non-blocking and no connections
are present to be accepted.
Various Linux kernels can return various other errors such
as EMFILE, EINVAL, ENOSR, ENOBUFS, EAGAIN, EPERM, ECONNA-
BORTED, ESOCKTNOSUPPORT, EPROTONOSUPPORT, ETIMEDOUT, ERES-
SVr4, 4.4BSD (the accept function first appeared in BSD
4.2). IRIX documents additional errors EMFILE and ENFILE.
Solaris documents additional errors EINTR, ENODEV, ENOMEM,
ENOSR and EPROTO.
bind(2), connect(2), listen(2),