|
|
|
|
|
|
|
|
HP-UX Reference Volume 3 of 5 > a
accept(2) |
|
NAMEaccept — accept a connection on a socket DESCRIPTIONThe accept() system call is used with connection-based socket types, such as SOCK_STREAM. The argument, s, is a socket descriptor created with socket(), bound to a local address by bind(), and listening for connections after a listen(). accept() extracts the first connection on the queue of pending connections, creates a new socket with the same properties as s, and returns a new file descriptor, ns, for the socket. If no pending connections are present on the queue and nonblocking mode has not been enabled with the fcntl() O_NONBLOCK or O_NDELAY flags or the ioctl() FIOSNBIO request, accept() blocks the caller until a connection is present. O_NONBLOCK and O_NDELAY are defined in <sys/fcntl.h> (see fcntl(2), fcntl(5), and socket(7)). FIOSNBIO and the equivalent request FIONBIO are defined in <sys/ioctl.h>, although use of FIONBIO is not recommended (see ioctl(2), ioctl(5), and socket(7)). If the socket has nonblocking mode enabled and no pending connections are present on the queue, accept() returns an error as described below. The accepted socket, ns, cannot be used to accept more connections. The original socket s remains open for incoming connection requests. To determine whether a listening socket has pending connection requests ready for an accept() call, use select() for reading. The argument addr should point to a socket address structure. The accept() call fills in this structure with the address of the connecting entity, as known to the underlying protocol. In the case of AF_UNIX sockets, the peer's address is filled in only if the peer had done an explicit bind() before doing a connect(). Therefore, for AF_UNIX sockets, in the common case, when the peer had not done an explicit bind() before doing a connect(), the structure is filled with a string of nulls for the address. The format of the address depends upon the protocol and the address-family of the socket s. The argument addrlen is a pointer to a variable. Initially, the variable should contain the size of the structure pointed to by addr. On return, it contains the actual length (in bytes) of the address returned. If the memory pointed to by addr is not large enough to contain the entire address, only the first addrlen bytes of the address are returned. If addr is NULL or addrlen contains 0, the connecting entity's address will not be returned. The fcntl() O_NONBLOCK and O_NDELAY flags and ioctl() FIOSNBIO request are all supported. These features interact as follows:
AF_CCITT onlyThe addr parameter to accept() returns addressing information for the connecting entity, except for the x25ifname[] field of addr which contains the name of the local X.25 interface through which the connection request arrived. Call-acceptance can be controlled with the ioctl() X25_CALL_ACPT_APPROVAL request (see socketx25(7)). RETURN VALUEUpon successful completion, accept() returns a nonnegative integer which is a descriptor for the accepted socket. If an error occurs, accept() returns -1 and sets errno to indicate the cause. ERRORSIf accept() fails, errno is set to one of the following values:
OBSOLESCENCECurrently, the socklen_t and size_t types are the same size. This is compatible with both the UNIX 95 and UNIX 98 profiles. However, in a future release, socklen_t might be a different size. In that case, passing a size_t pointer will evoke compile-time warnings, which must be corrected in order for the application to behave correctly. Applications that use socklen_t now, where appropriate, will avoid such migration problems. On the other hand, applications that need to be portable to the UNIX 95 profile should follow the X/Open specification (see xopen_networking(7)). FUTURE DIRECTIONCurrently, the default behavior is the HP-UX BSD Sockets; however, it might be changed to X/Open Sockets in a future release. At that time, any HP-UX BSD Sockets behavior that is incompatible with X/Open Sockets might be obsoleted. Applications that conform to the X/Open specification now will avoid migration problems (see xopen_networking(7)). |
||||||||||||||||||||||||||||||||||||
|
||
|
|
|
|||||||||||||
|
|||||||||||||
