tech-userlevel archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

Re: inetd tests failing

>>> [inetd reusing preforked processes after use]
>> This doesn't even make sense unless (a) you keep a separate list for
>> each service, (b) the daemon is expecting this (and thus signals its
>> doneness by some means other than exiting), (c) you invent some
>> interface for passing each new connection to an existing daemon
>> process, and (d) you make all the daemons - including admin-provided
>> legacy daemons - handle it.
> inetd is already keeping lists of what ports to listen on, what to
> exec when something connects for each service so I don't see an extra
> list as a big issue.

True; that is probably the smallest of the items I listed.

> There doesn't need to be any concept of "doneness" here, the daemon
> listens on stdin, writes on stdout, inetd sets up pipes to each
> preforked child and just round robins the connections to the child
> processes.

This is possible for only a restricted set of services (those that are
at least conceptually datagram services, more or less).  For example, I
have a machine with an inetd entry which uses a script running nc to
forward connections to a VNC server on another machine.  Given the VNC
protocol, this cannot possibly work with a scheme such as you outline.

Was the discussion restricted to only such a subset of services?  If
so, my apologies; that was not clear to me.

The rest of your message reads as though you are assuming, more or
less, a stateless datagram service.  If this was intended to apply to
only such services, then, sure, it's fine, but of sharply limited
value.  If not, I can't see how it could ever work for things such as
my VNC forwarder above.

/~\ The ASCII				  Mouse
\ / Ribbon Campaign
 X  Against HTML
/ \ Email!	     7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B

Home | Main Index | Thread Index | Old Index