View Source: accept(2) - Waikato Linux Users Group

Edit PageHistory Diff Info LikePages
ACCEPT
!!!ACCEPT
----
!!NAME


accept - accept a connection on a socket
!!SYNOPSIS


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


 __int accept(int__ ''s''__, struct sockaddr *__''addr''__, socklen_t *__''addrlen''__);__

!!DESCRIPTION

The __accept__ function is used with connection-based
socket types (__SOCK_STREAM__, __SOCK_SEQPACKET__ 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 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.

!!NOTES

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

!!RETURN VALUE

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

!!ERROR HANDLING

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 operation 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], [EPROTO], [ENOPROTOOPT], [EHOSTDOWN], [ENONET],
[EHOSTUNREACH], [EOPNOTSUPP], and [ENETUNREACH].
!!ERRORS


[EAGAIN] or [EWOULDBLOCK]

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

;[EBADF]: The descriptor is invalid.
;[ENOTSOCK]: The descriptor references a file, not a socket.
;[EOPNOTSUPP]: The referenced socket is not of type __SOCK_STREAM__.
;[EFAULT]: The ''addr'' parameter is not in a writable part of the user address space.
;[EPERM]: Firewall rules forbid connection.
;[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.

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 [EMFILE],
[EINVAL], [ENOSR], [ENOBUFS], [EPERM],
[ECONNABORTED], [ESOCKTNOSUPPORT],
[EPROTONOSUPPORT], [ETIMEDOUT],[ERESTARTSYS].
!!CONFORMING TO

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]).
SUSv2 documents errors [EAGAIN], [EBADF], [ECONNABORTED], [EFAULT],
[EINTR], [EINVAL], [EMFILE], [ENFILE], [ENOBUFS], [ENOMEM], [ENOSR],
[ENOTSOCK], [EOPNOTSUPP], [EPROTO], [EWOULDBLOCK].

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.

!!NOTE

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 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).''
!!SEE ALSO

bind(2), connect(2), listen(2), select(2), socket(2), CategorySocketSysCalls
30 pages link to accept(2):
This page is a man page (or other imported legacy content). We are unable to automatically determine the license status of this page.
Last edited on Sunday, June 22, 2003 12:17:47 pm by PerryLorier
Edit PageHistory Diff Info LikePages