Subject: Re: Proposal: socketfrom()
To: NetBSD Networking Technical Discussion List <tech-net@NetBSD.org>
From: Sam Leffler <firstname.lastname@example.org>
Date: 07/07/2007 13:00:26
Greg A. Woods wrote:
> At Thu, 5 Jul 2007 22:14:07 -0400, Thor Lancelot Simon wrote:
> Subject: Re: Proposal: socketfrom()
>> They do, and always were intended to -- but we had a bug for many years
>> that caused the watermarks and timeouts to not be copied. I just fixed
>> it a few days ago.
>> Notoriously, Linux does not propagate this state from the listen socket
>> to the accepted sockets, though the Berkeley documentation has always
>> been pretty clear that that is part of the API.
> I don't necessarily want to make excuses for Linux, but this fact is
> certainly not documented very well, just as the Linux (mis)behaviour
> attests. Saying simply that the new socket has the same "properties" as
> the listen socket is very vague, and it wasn't enough to clue me in.
> I did finally find a concrete reference. Stevens said in UNIX Network
> Programming Vol. 1, 2nd edition, p. 183 section 7.4:
> The following socket options are inherited by a connected TCP
> socket from the listening socket (pp. 462-463 of TCPv2):
> SO_DEBUG, SO_DONTROUTE, SO_KEEPALIVE, SO_LINGER, SO_OOBLINE,
> SO_RRVBUF, and SO_SNDBUF.
> (there is also a rationale given for why some options must be inherited
> It's no wonder the Linux kernel isn't doing the same thing -- they're
> not likely to reproduce behaviour that's not documented clearly in the
> manual page.
> "properties" could be read to only include the socket type and the local
> address the socket is bound to. After all getsockopt(2) is quite
> careful to use only the word "options" and never the word "properties".
> An option setting could be a property of something, but nothing ever
> really comes out and says that they are for sure.
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