Subject: Re: Proposal: socketfrom()
To: NetBSD Networking Technical Discussion List <>
From: Greg A. Woods <>
List: tech-net
Date: 07/05/2007 17:54:36
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: quoted-printable

At Thu, 5 Jul 2007 14:48:34 -0400, David Maxwell wrote:
Subject: Re: Proposal: socketfrom()
> It sounded like Thor's application creates new sockets often enough that
> it suffer from not having defaults. So, per-process defaults might work
> in his case, but it's not hard to imagine a more general solution where
> an application creates two different types of sockets often - maybe even
> interleaving them - and having to switch the defaults back and forth
> every time wouldn't help much.

I'm having a bit of a hard time imagining such an application....  :-)

However, in such an application where different types of sockets are
created often though there may not be any need to change the defaults?.

This changing of the defaults idea is really only to solve performance
problems where nearly identical sockets are created in great numbers and
where the system-wide socket option defaults are radically different
from what is required (i.e. where many setsockopt() calls would be
necessary for each socket being created).

I have less trouble imagining other applications like Thor's, though the
one or two similar to what I imagine and which I've examined (including
"pen") don't set any options on the sockets they create frequently.

Unless perhaps you're talking about options for sockets created by
accept()?  Changing the defaults for the process works for them too, and
perhaps that's the only way to do it without yet another system call.
If the loop is "accept(); ... socket();" and each needs different
options then my "defaults" idea still works assuming it's interface also
allows the user to set different defaults for accept() vs. socket()
sockets (and of different socket types, AF_*'s, etc., etc., etc.).

I don't know off-hand of any applications which call setsockopt() on
sockets created by accept(), though of course there may be many I don't
know of.

						Greg A. Woods

H:+1 416 218-0098 W:+1 416 489-5852 x122 VE3TCP RoboHack <>
Planix, Inc. <>       Secrets of the Weird <>

Content-Type: application/pgp-signature
Content-Transfer-Encoding: 7bit

Version: PGPfreeware 5.0i for non-commercial use
MessageID: 0WI8vB1H7CTIWkv3RdmgxJPYIEtY2QVw