Skip site navigation (1)Skip section navigation (2)

FreeBSD Manual Pages

  
 
  

home | help
ACCEPT(2)		  FreeBSD System Calls Manual		     ACCEPT(2)

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	ad-
     dress 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 pa-
     rameter; it should	initially contain the amount of	space pointed to by
     addr; on return it	will contain the actual	length (in bytes) of the ad-
     dress 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 con-
     nection request and not implying confirmation.  Confirmation can be im-
     plied 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	con-
     nection 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	call-
     ing 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 im-
     plementations which don't do so.  Linux is	an example of such implementa-
     tions.  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.

FreeBSD	13.0		       February	8, 2017			  FreeBSD 13.0

NAME | LIBRARY | SYNOPSIS | DESCRIPTION | RETURN VALUES | COMPATIBILITY | ERRORS | SEE ALSO | HISTORY

Want to link to this manual page? Use this URL:
<https://www.freebsd.org/cgi/man.cgi?query=accept&sektion=2&manpath=NetBSD+9.1>

home | help