4.3BSD-Reno/share/man/cat2/accept.0

ACCEPT(2)		      1990			ACCEPT(2)



NNAAMMEE
     accept - accept a connection on a socket

SSYYNNOOPPSSIISS
     ##iinncclluuddee <<ssyyss//ttyyppeess..hh>>
     ##iinncclluuddee <<ssyyss//ssoocckkeett..hh>>

     nnss == aacccceepptt((ss,, aaddddrr,, aaddddrrlleenn))
     iinntt nnss,, ss;;
     ssttrruucctt ssoocckkaaddddrr **aaddddrr;;
     iinntt **aaddddrrlleenn;;

DDEESSCCRRIIPPTTIIOONN
     The argument _s is a socket that has been created with
     _s_o_c_k_e_t(2), bound to an address with _b_i_n_d(2), and is listen-
     ing for connections after a _l_i_s_t_e_n(2).  _A_c_c_e_p_t extracts the
     first connection request on the queue of pending connec-
     tions, creates a new socket with the same properties of _s
     and allocates a new file descriptor, _n_s, for the socket.  If
     no pending connections are present on the queue, and the
     socket is not marked as non-blocking, _a_c_c_e_p_t blocks the
     caller until a connection is present.  If the socket is
     marked non-blocking and no pending connections are present
     on the queue, _a_c_c_e_p_t returns an error as described below.
     The accepted socket, _n_s, may not be used to accept more con-
     nections.	The original socket _s remains open.

     The argument _a_d_d_r is a result parameter that is filled in
     with the address of the connecting entity, as known to the
     communications layer.  The exact format of the _a_d_d_r parame-
     ter is determined by the domain in which the communication
     is occurring.  The _a_d_d_r_l_e_n is a value-result parameter; it
     should initially contain the amount of space pointed to by
     _a_d_d_r; on return it will contain the actual length (in bytes)
     of the address returned.  This call is used with
     connection-based socket types, currently with SOCK_STREAM.

     It is possible to _s_e_l_e_c_t(2) a socket for the purposes of
     doing an _a_c_c_e_p_t by selecting it for read.

     For certain protocols which require an explicit confirma-
     tion, such as ISO or DATAKIT, one should think of accept as
     merely dequeueing the next connection request, and not in of
     itself implying confirmation.  Confirmation can be implied
     by a normal read or write on the new file desciptor, and
     rejection can be implied by closing the new socket.

     One can obtain user connection request data without confirm-
     ing the connection by issuing a recvmsg call with an
     msg_iovlen of 0 and a non-zero msg_controllen, or by issuing
     a _g_e_t_s_o_c_k_o_p_t(2) request.  Similarly, one can provide user
     connection rejection information by issuing a sendmsg call



Printed 7/27/90                May				1






ACCEPT(2)		      1990			ACCEPT(2)



     with providing only the control information, or by calling
     _s_e_t_s_o_c_k_o_p_t(2).

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

EERRRROORRSS
     The _a_c_c_e_p_t will fail if:

     [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 _a_d_d_r parameter is not in a writable
			 part of the user address space.

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

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




























Printed 7/27/90                May				2