Re: xinetd feature: daemons that listen on multiple ports

Rob Braun <[email protected]> writes:

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

These are all the regular inetd advantages. We know these. But what
daemon serves a TCP and UDP request at the same time FOR THE SAME
REQUEST? I fail to see which daemon would use two sockets for one
request, synchronization of communiation alone is so expensive this is
prohibitive. The client uses TCP or UDP, but not both at the same time.

IF there is benefit in serving several IP protocols via several sockets
at the same time, the services are already implementing that stuff, and
such features will not go away (squid comes to mind).

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

Such convienience features are wasted efforts. Slapping on the "daemon
programmer hat" (I maintain the leafnode NNTP software), I'm not going
to use such features because that makes my software behave differently
depending on what inetd incarnation the user uses. This entails:

- more code effort to make use of such convenience stuff

- more testing is necessary, in more different parallel code paths

- you need to request more information from users when supporting them

Example: Some information about that is available in DJB's UCSPI
protocol that sets some environment variables describing the remote
site, say TCPREMOTEINFO, TCPREMOTEIP and TCPREMOTEHOST. All it takes to
access that information is a getenv(3), still I'm not doing it because
that information is not available when the software starts from inetd or
xinetd, so I'll have to add my own lookup-and-resolve stuff to add
logging anyways. And once I've got that implemented and debugged,
there's no need to add more code to access such convenience information
because I already have 100% working code to retrieve the very same
information.

I fail to see a) how your suggestion would work, b) what its field of
application might be. Frankly, I don't see use.

I don't want to stifle innovation, but I do fear you're going to produce
dead code that will see bugs found years ahead from now.

inetds are expected to be VERY stable interfaces, and daemons will use
just the lowest common denominator.

-- 
Matthias Andree