>>> [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 mo...@rodents-montreal.org / \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B
