Unix/Linux Go Back    

RedHat 9 (Linux i386) - man page for accept (redhat section 2)

Linux & Unix Commands - Search Man Pages
Man Page or Keyword Search:   man
Select Man Page Set:       apropos Keyword Search (sections above)

ACCEPT(2)			    Linux Programmer's Manual				ACCEPT(2)

       accept - accept a connection on a socket

       #include <sys/types.h>
       #include <sys/socket.h>

       int accept(int s, struct sockaddr *addr, socklen_t *addrlen);

       The  accept  function  is  used with connection-based socket types (SOCK_STREAM, SOCK_SEQ-
       PACKET and SOCK_RDM).  It extracts the first connection request on the  queue  of  pending
       connections,  creates  a  new  connected  socket with mostly the same properties as s, and
       allocates a new file descriptor for the socket, which  is  returned.   The  newly  created
       socket  is  no longer in the listening state.  The original socket s is unaffected by this
       call. Note that any per file descriptor flags (everything that can be set with the F_SETFL
       fcntl, like non blocking or async state) are not inherited across an accept.

       The  argument s is a socket that has been created with socket(2), bound to a local address
       with bind(2), and is listening for connections after a listen(2).

       The argument addr is a pointer to a sockaddr structure. This structure is filled  in  with
       the  address  of  the  connecting entity, as known to the communications layer.	The exact
       format of the address passed in the addr parameter is determined by  the  socket's  family
       (see  socket(2)	and the respective protocol man pages).  The addrlen argument is a value-
       result parameter: it should initially contain the size of  the  structure  pointed  to  by
       addr; on return it will contain the actual length (in bytes) of the address returned. When
       addr is NULL nothing is filled in.

       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 EAGAIN.

       In order to be notified of incoming connections on a socket,  you  can  use  select(2)  or
       poll(2).   A  readable  event will be delivered when a new connection is attempted and you
       may then call accept to get a socket for that connection.  Alternatively, you can set  the
       socket to deliver SIGIO when activity occurs on a socket; see socket(7) for details.

       For  certain  protocols which require an explicit confirmation, such as DECNet, accept can
       be thought of as merely dequeuing the next connection request and not  implying	confirma-
       tion.   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. Currently only  DECNet  has  these
       semantics on Linux.

       There  may  not	always be a connection waiting after a SIGIO is delivered or select(2) or
       poll(2) return a readability event because the connection might have been  removed  by  an
       asynchronous  network  error  or  another thread before accept is called.  If this happens
       then the call will block waiting for the next connection to arrive.  To ensure that accept
       never blocks, the passed socket s needs to have the O_NONBLOCK flag set (see socket(7)).

       The call returns -1 on error.  If it succeeds, it returns a non-negative integer that is a
       descriptor for the accepted socket.

       Linux accept passes already-pending network errors on the new socket as an error code from
       accept.	This behaviour differs from other BSD socket implementations. For reliable opera-
       tion the application should detect the network  errors  defined	for  the  protocol  after
       accept  and  treat  them  like  EAGAIN  by retrying. In case of TCP/IP these are ENETDOWN,

       accept shall fail if:

	      The socket is marked non-blocking and no connections are present to be accepted.

       EBADF  The descriptor is invalid.

	      The descriptor references a file, not a socket.

	      The referenced socket is not of type SOCK_STREAM.

       EINTR  The system call was interrupted by a signal that was caught before a valid  connec-
	      tion arrived.

	      A connection has been aborted.

       EINVAL Socket is not listening for connections.

       EMFILE The per-process limit of open file descriptors has been reached.

       ENFILE The system maximum for file descriptors has been reached.

       accept may fail if:

       EFAULT The addr parameter is not in a writable part of the user address space.

	      Not  enough free memory.	This often means that the memory allocation is limited by
	      the socket buffer limits, not by the system memory.

       EPROTO Protocol error.

       Linux accept may fail if:

       EPERM  Firewall rules forbid connection.

       In addition, network errors for the new socket and as defined  for  the	protocol  may  be
       returned.  Various  Linux  kernels can return other errors such as ENOSR, ESOCKTNOSUPPORT,
       EPROTONOSUPPORT, ETIMEDOUT.  The value ERESTARTSYS may be seen during a trace.

       SVr4, 4.4BSD (the accept function first appeared in BSD 4.2).  The BSD man page	documents
       five  possible  error  returns  (EBADF, ENOTSOCK, EOPNOTSUPP, EWOULDBLOCK, EFAULT).  SUSv3

       Linux accept does _not_ inherit socket flags like O_NONBLOCK.  This behaviour differs from
       other BSD socket implementations.  Portable programs should not rely on this behaviour and
       always set all required flags on the socket returned from accept.

       The third argument of accept was originally declared as an `int	*'  (and  is  that  under
       libc4  and  libc5  and  on many other systems like BSD 4.*, SunOS 4, SGI); a POSIX 1003.1g
       draft standard wanted to change it into a `size_t *', and that is what it is for SunOS  5.
       Later POSIX drafts have `socklen_t *', and so do the Single Unix Specification and glibc2.
       Quoting Linus Torvalds: _Any_ sane library _must_ have "socklen_t" be  the  same  size  as
       int.   Anything	else  breaks any BSD socket layer stuff.  POSIX initially _did_ make it a
       size_t, and I (and hopefully others, but obviously not too many) complained to  them  very
       loudly  indeed.	Making it a size_t is completely broken, exactly because size_t very sel-
       dom is the same size as "int" on 64-bit architectures, for example.  And it  _has_  to  be
       the same size as "int" because that's what the BSD socket interface is.	Anyway, the POSIX
       people eventually got a clue, and created "socklen_t".  They shouldn't have touched it  in
       the  first place, but once they did they felt it had to have a named type for some unfath-
       omable reason (probably somebody didn't like losing face over  having  done  the  original
       stupid thing, so they silently just renamed their blunder).

       bind(2), connect(2), listen(2), select(2), socket(2)

Linux 2.2 Page				    2002-04-23					ACCEPT(2)
Unix & Linux Commands & Man Pages : ©2000 - 2018 Unix and Linux Forums

All times are GMT -4. The time now is 11:53 PM.