Re: xinetd feature: daemons that listen on multiple ports

You make very good points and have a persuasive argument.
You've convinced me that this feature is not worthwhile,
and all the problems that this would solve, can be solved
better in other ways.
Thank you for the input.

Rob

On Thu, Aug 07, 2003 at 12:57:22AM +0200, Matthias Andree wrote:
> 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
> _______________________________________________
> xinetd mailing list
> [email protected]
> http://www.xinetd.org/mailman/listinfo/xinetd