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/05/2007 20:39:39
--pgp-sign-Multipart_Thu_Jul__5_20:39:39_2007-1
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: quoted-printable

At Thu, 5 Jul 2007 18:08:42 -0400 (EDT), der Mouse wrote:
Subject: Re: Proposal: socketfrom()
>=20
> Does it?  accept() currently, I think, inherits options settings and
> such from the listening socket (and thus already has a template socket
> built in).  There's no need to setsockopt on accept()-created sockets
> unless you want the new connection's socket to have different options
> from those on the listening socket - which basically means, there's
> some option with meaning both for listening and connected sockets, but
> you want them different.  I'm having trouble thinking of an example,
> but that could just be betraying my ignorance of the variety of socket
> options out there.

I'm not even sure that sockets returned from accept() do in fact inherit
their options from the listening socket.  A quick browse of the accept()
code and annotations in TCP/IP Illustrated Vol2 suggests not, but I may
be mistaken.

Perhaps SO_KEEPALIVE and maybe SO_DEBUG would be set only on the
accept()ed sockets, or maybe even only on some of them?  I dunno -- I'm
just grasping at examples out of thin air.

There's also the potential need to adjust buffer sizes and hi/lo-water
marks, timeouts, etc., all on a per-accept() basis, though again I'm
just thinking out loud....

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

-----BEGIN PGP SIGNATURE-----
Version: PGPfreeware 5.0i for non-commercial use
MessageID: t3sIbm4JCGI+ibVQ2cUVfKCDHjs3mCKw

iQA/AwUBRo2PS2Z9cbd4v/R/EQJwgQCeMZyLZ41HyfB0gsZcpfNn7Oc6uc8AoM/9
+0GF17Q31GC+2h0hAmg3r1cd
=pdUV
-----END PGP SIGNATURE-----

--pgp-sign-Multipart_Thu_Jul__5_20:39:39_2007-1--