Subject: Re: Proposal: socketfrom()
To: NetBSD Networking Technical Discussion List <tech-net@NetBSD.org>
From: Greg A. Woods <woods@planix.com>
List: tech-net
Date: 07/08/2007 16:15:00
--pgp-sign-Multipart_Sun_Jul__8_16:14:56_2007-1
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: quoted-printable
At Sat, 07 Jul 2007 13:00:26 -0700, Sam Leffler wrote:
Subject: Re: Proposal: socketfrom()
>
> Hmm, I thought it was pretty clear in the original sockets api
> documentation I wrote but it has been a while and many hands have
> touched things...
Where might I find something close to the original, either online or in
printed form?
Which reminds me, I need to get a copy of the third edition of the UNIX
Network Programming set! :-)
Looks like the POSIX folks read accept(2) the same way I did and
interpreted "properties" to mean only the socket type, protocol, and
address family:
http://www.opengroup.org/onlinepubs/009695399/functions/accept.html
The accept() function shall extract the first connection on the
queue of pending connections, create a new socket with the same
socket type protocol and address family as the specified socket,
and allocate a new file descriptor for that socket.
Sadly the socket API documented by Douglas Comer and David Stevens in
their Internetworking with TCP/IP Vol 3 (client-server programming and
applications, Linux/POSIX Sockets Version) barely even mentions socket
options, and certainly doesn't mention them in context of the accept()
call.
Now that I take the time to look, I see that the Linux accept(2) manual
page does explicitly deny inheritance of at least F_SETFL flags by the
new connected socket:
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 Linux accept(2) manual page then goes on to claim conformance with
4.4BSD with the following caveat:
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.
--
Greg A. Woods
H:+1 416 218-0098 W:+1 416 489-5852 x122 VE3TCP RoboHack <woods@robohack.ca>
Planix, Inc. <woods@planix.com> Secrets of the Weird <woods@weird.com>
--pgp-sign-Multipart_Sun_Jul__8_16:14:56_2007-1
Content-Type: application/pgp-signature
Content-Transfer-Encoding: 7bit
-----BEGIN PGP SIGNATURE-----
Version: PGPfreeware 5.0i for non-commercial use
MessageID: HdukgNWvbGLuUFeUet8HYWEUZnK4ahUG
iQA/AwUBRpFFwGZ9cbd4v/R/EQKQigCggdec7G5Yi+5A2dWjZLoocYHRKrAAoMEm
lIgzIWe4dP35kQzuufl/k2Y0
=m/pj
-----END PGP SIGNATURE-----
--pgp-sign-Multipart_Sun_Jul__8_16:14:56_2007-1--