--pgp-sign-Multipart_Fri_Jul__6_17:33:39_2007-1
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: quoted-printable

At Thu, 5 Jul 2007 22:14:07 -0400, Thor Lancelot Simon wrote:
Subject: Re: Proposal: socketfrom()
>=20
> 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.
>=20
> 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.

--=20
						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_Fri_Jul__6_17:33:39_2007-1
Content-Type: application/pgp-signature
Content-Transfer-Encoding: 7bit

-----BEGIN PGP SIGNATURE-----
Version: PGPfreeware 5.0i for non-commercial use
MessageID: 0J49qEsG8TpgKK4qQ2OnnBTPYeAEnYX6

iQA/AwUBRo61M2Z9cbd4v/R/EQI0UQCg96nxvJUCtfaZb20jxtNaqfMTSJ0AnRWK
NAYVkYSDcFiDV47Ns8cUOGfJ
=Lz3o
-----END PGP SIGNATURE-----

--pgp-sign-Multipart_Fri_Jul__6_17:33:39_2007-1--