Re: xinetd feature: daemons that listen on multiple ports

Rob Braun <[email protected]> writes:

> There are several daemons out there that listen on multiple ports.
> Portmap listens on both udp and tcp sockets.  Individual clients
> do not use both simultaneously, but different clients use different
> protocols to get at the same information.  The daemon needs to
> respond to requests on both.  Currently, it can't be launched from
> an inetd reliably, because there is no way to pass multiple socket
> descriptors to the daemon.

The rpcbind = portmap issue is a rather special one, and so special that
its solution isn't in good hands of a general-purpose inetd.

The rpcbind case is special because all rpcbind implementations I've
seen so far keep their registrations in memory only, so the daemon must
be persistent. If you implemented an rpcbind that used a concurrent data
base (single-writer, multi-reader) such as BerkeleyDB or TDB, you could
write a simple inetd-launchable rpcbind that processed the request and
then exited. Apparently no-one felt a pain big enough to sit down and do
this.

The next reason is that if a system needs to run rpcbind (NFS exports or
something), the demand for rpcbind will arise at boot time already, so
rpcbind will always be run this way or the other. Running it from inetd
doesn't gain from the "on-demand" trait.

Some RPC services that aren't used often might profit (ypxfrd or
something), but as they have to have network code to register with
rpcbind, there's not much to be gained here either, and I wonder how
you'd serialize the single-threaded ones. It's trivial when there's one
process running, but what do you do when two requests arrive "at the
same time" with different IP protocols? A single-threaded process is
easy, but you're then going to implement locking in xinetd as well so
you can avoid running two daemons for a single-threaded service and all
that. Looking at Solaris' inetd.conf, all RPC services listed in
inetd.conf (there are standalone RPC services, too) are
single-threaded. I can't tell if these listen for TCP and UDP at the
same time.

Similar latency considerations apply to DNS resolvers, latency will be a
show-stopper here.

> However, it may be easy to modify the existing daemons so they can
> be launched out of inetd or standalone, like so many other daemons
> (sshd, samba, proftpd, etc.)

There is no need to add code to xinetd for that purpose. If I was to
program a new daemon, and it allowed inetd configurations without pain
(like sshd key generation overhead which is a real hog on slower
machines), I'd rather not implement a standalone mode at all. There are
so many inetd replacements: xinetd, ucspi-tcp, ipsvd, sock, socket,
netcat, g2s, ...

-- 
Matthias Andree