On 06/09/2016 10:42, Jonathan de Boyne Pollard wrote:
One dictum is that if you're using the "LISTEN" protocol for any
UCSPI use-case, you are doing it wrong. The name "LISTEN" in
"LISTEN_FDS" is a big clue. It's not for accepted socket file
descriptors. It's for listening ones.
UCSPI deals in accepted connections, conversely.
That's right; sorry for entertaining the confusion. I was focusing on the
"pass open fds other than 0, 1 and 2 from the caller to the daemon" aspect,
without considering the nature of the fds.
I am still of the opinion that the nature of the fds should be a
convention between the caller and the daemon. The most interesting thing
about UCSPI is that it only handles byte streams, so any fd you can
read() from and write() to generally works.
A socket that hasn't been obtained by accept() is different in that it
has a lot of states (created, bound, listening, and maybe more) in which
you still can't read/write. Each of those states is dynamically testable,
but it's a lot cleaner if the daemon knows what state the fd it receives
is supposed to be in.
If you think that "here's a bunch of file descriptors" is the
protocol, then you've missed a subtlety. The protocol is that the
list of file descriptors is *ordered*, by the system
administrator/package writer.
Oh, yes, of course it's ordered. It's a list, not a set - else you
could never make it work without labels. I just find it ugly to test
the type of the received fd dynamically, see below.
They could equally well define something like "You
specify my control listening FIFO first, my TCP4 service listening
socket second, and my TCP6 service listening socket third in the
list.". How the ordered list of file descriptors is treated is
defined by the service programs themselves.
Yes. That was the point I was making: the simplest possible API is a
hardcoded convention from the daemon. LISTEN_FDS just makes it less
flexible, since the control listening FIFO will be 3, the TCP4 listening
socket will be 4 and the TCP6 listening socket will be 5, and the
daemon is not free to use those for another purpose.
But Daniel's answer, as I understood it, was that some daemons may want
to get *several* fds for the same service: for instance, to listen to a
dynamically specified number of IPv4 addresses in order to provide TCP4
service to all of them. In that case, it is not possible anymore to rely
on fixed fd numbers: and you need to either dynamically test the type
of the fds you receive, or use a "purpose label -> set of fds with that
purpose" map. The latter is a lot more aesthetically pleasing to me than
the former.
--
Laurent
