1.\" Copyright (c) 1983, 1990, 1991 The Regents of the University of California. 2.\" All rights reserved. 3.\" 4.\" Redistribution and use in source and binary forms, with or without 5.\" modification, are permitted provided that the following conditions 6.\" are met: 7.\" 1. Redistributions of source code must retain the above copyright 8.\" notice, this list of conditions and the following disclaimer. 9.\" 2. Redistributions in binary form must reproduce the above copyright 10.\" notice, this list of conditions and the following disclaimer in the 11.\" documentation and/or other materials provided with the distribution. 12.\" 3. All advertising materials mentioning features or use of this software 13.\" must display the following acknowledgement: 14.\" This product includes software developed by the University of 15.\" California, Berkeley and its contributors. 16.\" 4. Neither the name of the University nor the names of its contributors 17.\" may be used to endorse or promote products derived from this software 18.\" without specific prior written permission. 19.\" 20.\" THIS SOFTWARE IS PROVIDED BY THE REGENTS AND CONTRIBUTORS ``AS IS'' AND 21.\" ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE 22.\" IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE 23.\" ARE DISCLAIMED. IN NO EVENT SHALL THE REGENTS OR CONTRIBUTORS BE LIABLE 24.\" FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL 25.\" DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS 26.\" OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) 27.\" HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT 28.\" LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY 29.\" OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF 30.\" SUCH DAMAGE. 31.\" 32.\" from: @(#)accept.2 6.6 (Berkeley) 4/29/91 33.\" $Id: accept.2,v 1.5 1994/01/10 23:54:08 jtc Exp $ 34.\" 35.Dd April 29, 1991 36.Dt ACCEPT 2 37.Os BSD 4.2 38.Sh NAME 39.Nm accept 40.Nd accept a connection on a socket 41.Sh SYNOPSIS 42.Fd #include <sys/types.h> 43.Fd #include <sys/socket.h> 44.Ft int 45.Fn accept "int s" "struct sockaddr *addr" "int *addrlen" 46.Sh DESCRIPTION 47The argument 48.Fa s 49is a socket that has been created with 50.Xr socket 2 , 51bound to an address with 52.Xr bind 2 , 53and is listening for connections after a 54.Xr listen 2 . 55The 56.Fn accept 57argument 58extracts the first connection request 59on the queue of pending connections, creates 60a new socket with the same properties of 61.Fa s 62and allocates a new file descriptor 63for the socket. If no pending connections are 64present on the queue, and the socket is not marked 65as non-blocking, 66.Fn accept 67blocks the caller until a connection is present. 68If the socket is marked non-blocking and no pending 69connections are present on the queue, 70.Fn accept 71returns an error as described below. 72The accepted socket 73may not be used 74to accept more connections. The original socket 75.Fa s 76remains open. 77.Pp 78The argument 79.Fa addr 80is a result parameter that is filled in with 81the address of the connecting entity, 82as known to the communications layer. 83The exact format of the 84.Fa addr 85parameter is determined by the domain in which the communication 86is occurring. 87The 88.Fa addrlen 89is a value-result parameter; it should initially contain the 90amount of space pointed to by 91.Fa addr ; 92on return it will contain the actual length (in bytes) of the 93address returned. 94This call 95is used with connection-based socket types, currently with 96.Dv SOCK_STREAM . 97.Pp 98It is possible to 99.Xr select 2 100a socket for the purposes of doing an 101.Fn accept 102by selecting it for read. 103.Pp 104For certain protocols which require an explicit confirmation, 105such as 106.Tn ISO 107or 108.Tn DATAKIT , 109.Fn accept 110can be thought of 111as merely dequeuing the next connection 112request and not implying confirmation. 113Confirmation can be implied by a normal read or write on the new 114file descriptor, and rejection can be implied by closing the 115new socket. 116.Pp 117One can obtain user connection request data without confirming 118the connection by issuing a 119.Xr recvmsg 2 120call with an 121.Fa msg_iovlen 122of 0 and a non-zero 123.Fa msg_controllen , 124or by issuing a 125.Xr getsockopt 2 126request. 127Similarly, one can provide user connection rejection information 128by issuing a 129.Xr sendmsg 2 130call with providing only the control information, 131or by calling 132.Xr setsockopt 2 . 133.Sh RETURN VALUES 134The call returns \-1 on error. If it succeeds, it returns a non-negative 135integer that is a descriptor for the accepted socket. 136.Sh ERRORS 137The 138.Fn accept 139will fail if: 140.Bl -tag -width Er 141.It Bq Er EBADF 142The descriptor is invalid. 143.It Bq Er ENOTSOCK 144The descriptor references a file, not a socket. 145.It Bq Er EOPNOTSUPP 146The referenced socket is not of type 147.Dv SOCK_STREAM . 148.It Bq Er EFAULT 149The 150.Fa addr 151parameter is not in a writable part of the 152user address space. 153.It Bq Er EWOULDBLOCK 154The socket is marked non-blocking and no connections 155are present to be accepted. 156.El 157.Sh SEE ALSO 158.Xr bind 2 , 159.Xr connect 2 , 160.Xr listen 2 , 161.Xr select 2 , 162.Xr socket 2 163.Sh HISTORY 164The 165.Fn accept 166function appeared in 167.Bx 4.2 . 168