Thor Lancelot Simon wrote:
> I have an application that makes outbound TCP connections at a very high
> rate, so high that the overhead of additional system calls to set socket
> options considerably impacts performance.
>
> I could partially address this by adding a system call that sets multiple
> socket options at once (which, I think, would be a better API than
> setsockopt() anyway) but that gets rid of _all but one_ system call to
> set up the socket before connect(); I want to get rid of them all.
>
> I'd like to make it possible to set options on one "template" or "master"
> socket and then have them inherited by children, as listen()/accept() make
> possible for the other direction.  I'm thinking of something along the lines
> of this:
>
> int socketfrom(int template, int domain, int type, int protocol);
>
> Which would return a new socket using the socket options already set on
> socket "template".  If domain, type, and protocol don't match, this is
> an error (or perhaps it would be best to omit them entirely and just
> have one argument, the template socket.
>
> Opinions?

I dislike this approach becaues it is a new way to create a socket.

Currently you create a socket with socket(), have the system allocate
you a new one with accept() and...I think that is the limit.

I would rather see something like:

setsockopt(fd, SOL_SOCKET, SO_TEMPLATE,  &template, sizeof(template))

The next question is then how to define the "template" data structure
in such a way that it is extensible for arbitrary sockets.

Another reason that I prefer this approach because it is easier to
learn or adapt to use.  Also when reading new code, someone is
confronted with a "wtf is this socket option" rather than "wtf is
this socketfrom" and goes looking for socketfrom() in your app because
it isn't a widely known system call.

Darren