Re: xinetd feature: daemons that listen on multiple ports

On Wed, Aug 06, 2003 at 09:18:58PM +0200, Matthias Andree wrote:
> 
> 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).

Launching services from inetd isn't just for lazy programmers anymore.
An inetd can serve as a central network service management point.
If all or many of the system's network services are run out of an
inetd, they can easily or programmatically be controled through that
one interface, rather than teaching everything how to interface with
each particular application's start/stop/config setup.  In addition
to just being a funnel, performance benefits can be had.  Services
can be offered with near zero penalty if they aren't used, and are
instantly available if they are needed.  This can often result in 
faster boot times, since the daemons don't need to be paged in until
they are needed.

Obviously, for systems that need lower latency and handle higher
loads, launching daemons through an inetd is not desireable.  However,
given that the vast majority of machines with xinetd installed are
reasonably fast hardware, and rarely need the performance of a high
end server, this can be an overall win.  In many cases, the load
is just a few users who would rather have the services available
when needed.

> > 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.

True.  A simple call to getsockname() would return all of the
same information.  This would just be a convenience instead of
making the daemon iterate over all it's sockets doing getsockname().
Perhaps it would be simpler if the app just did those calls as needed.

Rob