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
> too)
> 
> 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
touched things...

	Sam