accept in translation

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

NAME
       accept, accept4 - accept a connection on a socket /* accept a connection on a socket */

SYNOPSIS
       #include <sys/types.h>          /* See NOTES */
       #include <sys/socket.h>

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

       #define _GNU_SOURCE             /* See feature_test_macros(7) */
       #include <sys/socket.h>

       int accept4(int sockfd, struct sockaddr *addr,
                   socklen_t *addrlen, int flags);

DESCRIPTION
       The  accept()  system  call  is  used  with  connection-based  socket types (SOCK_STREAM, SOCK_SEQPACKET).  It extracts the first connection request on the queue of pending connections for the  listening  socket,  sockfd, creates a new connected socket, and returns a new file descriptor referring to that socket.  The newly created socket is not in the listening state. The original socket sockfd is unaffected by this call.
	   /*accept functions are for connection-based sockets (SOCK_STREAM, SOCK_SEQPACKET). It selects the first connection request in the connection wait queue, then creates a new connection socket and returns a file descriptor pointing to that socket. The newly created socket will not be in the listening state, and the original socket (the socket pointed to by the socket descriptor in the accept parameter) will not be affected by the accept calling function (including file status flags, etc. )*/
	   
       The argument sockfd 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 /*sockfd parameter is a socket created by the socket function, the bind function binds the local address, and finally the listen function sets the socket for listening for connections. */
	     
       The argument addr is a pointer to a sockaddr structure. This structure is filled in with the address of the peer socket, as known to the communications layer. The exact format of the address returned addr is determined by the socket's address family (see socket(2) and the respective protocol man pages). When addr is NULL, nothing is filled in; in this case, addrlen is not used, and should also be NULL.
	   The /*addr parameter is a pointer to a sockaddr structure. This structure contains the address of the peer socket, which is known as the network layer. The exact format of addr depends on the address family of the socket (see socket(2) and the corresponding protocol man page). When addr == NULL, the accept function will not get any information, then the addrlen parameter is meaningless, then the last parameter should also be filled with NULL*/

       The addrlen argument is a value-result argument: the caller must initialize it to contain the size (in  bytes) of the structure pointed to by addr; on return it will contain the actual size of the peer address.
	   The /*addrlen parameter is a value result parameter: the caller must initialize it first, and this parameter is used to store the size (in bytes) of the structure pointed to by addr. When the function returns, addrlen will bring back the size of the address structure of the other party*/
	   	   
       The returned address is truncated if the buffer  provided is too small; in this case, addrlen will return a value greater than was supplied to the call.
	   /* If the provided buffer is too small, the returned address will be truncated; in this case, addrlen will return a value greater than the value provided for the call */

       If no pending connections are present on the queue, and the socket is  not  marked  as  nonblocking,  accept() blocks  the  caller until a connection is present.  If the socket is marked nonblocking and no pending connections are present on the queue, accept() fails with the error EAGAIN or EWOULDBLOCK.
	   /* If there are no waiting connections in the current queue, and the socket is not marked as non-blocking, the accept function will block the caller until there is a connection. If the socket is marked as non-blocking and there are no waiting connections in the current queue, the accept function will fail with an error code of EAGAIN or EWOULDBLOCK */

       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.
	   /*We can know the sockets currently added to the connection queue by calling the select function or the poll function. When a new request tries to connect, and at this time we call the accept function to create a socket, then we can implement the delivery of readable events. Of course, we can also set the socket to send a SIGIO signal immediately when the socket changes. For details, see socket(7)*/

       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 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. Currently only DECNet has these semantics on Linux.
	   /*For some protocols that require explicit confirmation, such as DECNet, the accept function can be regarded as just taking the next connection from the queue without confirmation. An acknowledgment is implied when ordinary read and write operations are performed on a new file descriptor, and a rejection is implied when the new socket is closed. Currently on Linux only DECNet has these meanings */

       If flags is 0, then accept4() is the same as accept(). The following values can be bitwise ORed in flags to obtain different behavior:
	   /*If the flag parameter is 0, the accept4 function is the same as the accept function. The following values ​​can be bitwise ORed in flags for different behavior. */

       SOCK_NONBLOCK   Set the O_NONBLOCK file status flag on the new open file description. Using this flag saves extra calls to fcntl(2) to achieve the same result.
	   /*SOCK_NONBLOCK Set the O_NONBLOCK (non-blocking) file status flag in the new open file description. Using this flag saves an extra call to fcntl to achieve the same result */

       SOCK_CLOEXEC    Set the close-on-exec (FD_CLOEXEC) flag on the new file descriptor. See the description of the O_CLOEXEC flag in open(2) for reasons why this may be useful.
	   /*SOCK_CLOEXEC Set the close-on-exec (FD_CLOEXEC) file status flag in the new open file description. See the description of the O_CLOEXEC flag in the open function for the purpose of setting this status flag. */	   

RETURN VALUE
		On  success, these system calls return a nonnegative integer that is a descriptor for the accepted socket. On error, -1 is returned, and errno is set appropriately.
		/* On success, these system calls will return a non-negative integer, which is the descriptor of the receiving socket; on failure, -1 is returned, and the error code is stored in errno */

		Error handling Linux accept() (and accept4()) passes already-pending network errors on the new socket as an error  code  from accept(). This  behavior differs from other BSD socket implementations.  For reliable operation the application should detect the network errors defined for the protocol after accept() and treat them  like  EAGAIN  by retrying.   In the case of TCP/IP, these are ENETDOWN, EPROTO, ENOPROTOOPT, EHOSTDOWN, ENONET, EHOSTUNREACH, EOPNOTSUPP, and ENETUNREACH.
		/*The error handling of Linux accept(and accept4) is implemented through a new socket on the network connected by both parties, and the error information transmitted by the socket is only the error code generated by the error of the accept function, that is The value of errno, which differs from other BSD socket implementations. For reliable operation, the application should detect network errors due to the protocol definition after the accept function, and treat it with retries like EAGAIN. In the case of TCP/IP includes: ENETDOWN, EPROTO, ENOPROTOOPT, EHOSTDOWN, ENONET, EHOSTUNREACH, EOPNOTSUPP, and ENETUNREACH*/

	ERRORS
       EAGAIN or EWOULDBLOCK The socket is marked nonblocking and no connections are present to be accepted. POSIX.1-2001  and POSIX.1-2008 allow either error to be returned for this case, and do not require these constants to have the same value, so a portable application should check for both possibilities.
	   /*EAGAIN or EWOULDBLOCK The socket is marked as non-blocking and there are no connections to accept. POSIX.1-2001 and POSIX.1-2008 allow an error to be returned for this case, and do not require these constants to have the same value, so portable applications should check for both possibilities */

       EBADF  The descriptor is invalid.
	   /* EBADF descriptor is invalid */

       ECONNABORTED A connection has been aborted.
	   /*ECONNABORTED connection terminated */

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

       EINTR  The system call was interrupted by a signal that was caught before a valid connection arrived; see signal(7).
	   /* The EINTR system call was interrupted by a signal that was caught before a valid connection arrived */

       EINVAL Socket is not listening for connections, or addrlen is invalid(e.g., is negative).
	   /*EINVAL socket is not a listening socket, or addrlen is invalid (eg, addrlen is negative)*/

       EINVAL (accept4()) invalid value in flags.
	   /*EINVAL accept4 function invalid flag setting*/

       EMFILE The per-process limit on the number of open file descriptors has been reached.
	   /*EMFILE has reached the upper limit of file descriptors that can be opened by each process*/

       ENFILE The system-wide limit on the total number of open files has been reached.
	   /*ENFILE has reached the system-wide limit on the total number of open files*/

       ENOBUFS, ENOMEM Not enough free memory. This often means that the memory allocation is limited by the socket buffer limits, not by the system memory.
	   /*ENOBUFS, ENOMEM Out of memory. This error generally means that the memory allocation is bounded by the socket buffer, not that there is no system memory */

       ENOTSOCK The file descriptor sockfd does not refer to a socket.
	   /*ENOTSOCK sockfd parameter is not a socket*/

       EOPNOTSUPP The referenced socket is not of type SOCK_STREAM.
	   /* The socket referenced by EOPNOTSUPP is not of type SOCK_STREAM */

       EPROTO Protocol error.
	   /*EPROTO protocol error*/

       In addition, Linux accept() may fail if:
	   /* In addition, the Linux accept function will also error if the following occurs */

       EPERM  Firewall rules forbid connection.
	   /*EPERM firewall settings prohibit connections*/

       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.
	   /* In addition, network errors for the new socket and errors defined in the protocol are also returned. Different Linux kernels also return some other problems, such as: ENOSR, ESOCKTNOSUPPORT, EPROTONOSUPPORT, ETIMEDOUT. Trace all the way back to see the value of ERESTARTSYS */

VERSIONS
       The accept4() system call is available starting with Linux 2.6.28; support in glibc is available starting with version 2.10.
	   /*accept4 system call function is only available from Linux 2.6.28; glibc support is available from 2.10*/

CONFORMING TO
       accept(): POSIX.1-2001, POSIX.1-2008, SVr4, 4.4BSD (accept() first appeared in 4.2BSD).
	   /*accept function first appeared in 4.2BSD*/

       accept4() is a nonstandard Linux extension.
	   /* The accept4 function is a non-standard Linux extension */

       On Linux, the new socket returned by accept() does not inherit file status flags such as O_NONBLOCK and O_ASYNC from the listening socket. This behavior differs from the canonical BSD sockets implementation. Portable programs should not rely on inheritance or noninheritance of file status flags and always explicitly set all required flags on the socket returned from accept().
	   /* On Linux, new sockets returned by the accept function do not inherit file status flags such as O_NONBLOCK and O_ASYNC from listening sockets. This differs from the canonical BSD socket implementation mechanism. Portable programs should not depend on whether the file state is inheritable, but should set all requirements on the corresponding flags of the socket when the accept function returns.
	   Portable programs should not rely on inheritance or non-inheritance of file status flags, and always explicitly set all required flags on sockets returned from accept(). */

NOTES
       POSIX.1-2001 does not require the inclusion of <sys/types.h>, and this header file is not required on Linux. However, some historical (BSD) implementations required this header file, and portable applications are probably wise to include it.
	   /*POSIX.1 does not need the <sys/types.h> header file, but it is required for historical reasons (eg: BSD), so it is better to add this header file*/
	 
       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 sockfd needs to have the O_NONBLOCK flag set (see socket(7)).
	   /* When a SIGIO signal is received or a select, poll function returns read ready does not always mean that there is a new connection waiting, because the connection is likely to be dropped by an asynchronous network error or another thread before the accept function is called. If this happens, the call will block and wait for the next connection to come. To ensure accept never blocks, the passed socket sockfd needs to be set to O_NONBLOCK flag (see socket(7))*/

   The socklen_t type /*socklen_t type*/
       The third argument of accept() was originally declared as an int * (and is that under libc4 and libc5  and  on many other systems like 4.x BSD, SunOS 4, SGI); a POSIX.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:
	   /* The third parameter of the function accept was originally declared as int * (in libc4 and libc5 and many other systems, such as BSD 4.x, SunOS 4, SGI); the POSIX.1g draft attempts to change it to type size_t * , SunOS 5 does this. Later POSIX drafts and the Single Unix Specification and glibc2 used socklen_t *. Quote from 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 seldom 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 unfathomable reason (probably somebody didn't like losing face over having done the original stupid thing,so they silently just renamed their blunder)."
	   /* Any sensible library function designer would definitely set the data type of 'socklen_t' to int. Otherwise it will break the padding of the BSD socket layer. POSIX started with size_t, and Linus Torvalds (he wished there were more, but apparently not many) tried to explain to them that using size_t was completely wrong, because size_t and int are not the same size in 64-bit structs , and the length of this parameter (that is, the third parameter of the accept function) must be the same as int, because this is the BSD socket interface standard. Finally, the POSIX guys found a solution, which is to create a New type socklen_t. Linux Torvalds said it was because they found their mistake but were too embarrassed to admit it to the big guys, so they created a new data type. */

EXAMPLE
       See bind(2).

SEE ALSO
       bind(2), connect(2), listen(2), select(2), socket(2), socket(7)

COLOPHON
       This page is part of release 4.04 of the Linux man-pages project.  A description of the  project,  information about reporting bugs, and the latest version of this page, can be found at http://www.kernel.org/doc/man-pages/.

Linux                                                 2015-12-28                                            ACCEPT(2)