Re: xinetd feature: daemons that listen on multiple ports

Rob Braun <[email protected]> writes:

> I'm thinking about adding a new feature to xinetd, and am seeking
> feedback on how best to implement some of it.
>
> Many daemons, such as portmap and modern mail daemons, listen on
> more than one port or the same port on tcp and udp.
> Currently, this essentially means they can't run out of an inetd, or
> they need to change their architecture so they can.

Why would such a daemon that already has networking code profit from
being run from xinetd? It will not serve TCP and UDP for the same
request, so either it can run from inetd the way it's always been (no
changes necessary) or it can't because it needs persistent in-core
storage that is too inefficient to load or prepare at start-up (ssh keys
come to mind, on slower machines or for keys with many thousand bits --
no changes necessary).

> 3) Have xinetd pick randomly which file descriptors in the
> process will contain which socket descriptors, then have
> the launched daemon recieve addrinfo structures describing
> which sockets are on which file descriptors.  

The daemon could just as well use getsockaddr. No extra information
passing needs to take place.

-- 
Matthias Andree