>> [I]t'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....  :-)

Consider something that creates a lot of transient connections, but
always in pairs - one long-haul, with option set A, and the other
local, with option set B.

> Unless perhaps you're talking about options for sockets created by
> accept()?  Changing the defaults for the process works for them too,

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 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.

I have the feeling I may have written one once, but, looking over the
list of socket options, I can't think which option(s) that could have
been, so I may be conflating it with other "options" such as O_NONBLOCK
that aren't really covered by this discussion.

/~\ The ASCII				der Mouse
\ / Ribbon Campaign
 X  Against HTML	       mouse@rodents.montreal.qc.ca
/ \ Email!	     7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B