Subject: Re: Proposal: socketfrom()
To: None <email@example.com>
From: Darren Reed <firstname.lastname@example.org>
Date: 07/05/2007 08:03:35
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.
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.