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 mouse%rodents-montreal.org@localhost
/ \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B
Home |
Main Index |
Thread Index |
Old Index