>> This is possible for only a restricted set of services (those that >> are at least conceptually datagram services, more or less). > I don't think it precludes tcp as long as they are stateless - http > is an obvious example
Ish. HTTP is stateless in the sense that consecutive requests/responses do not depend on one another. But at least some HTTP servers change their behaviour based on on getpeername(), and at least some HTTP requests/responses depend on reaching EOF on the socket (which as far as I know is not undoable and thus requires a new socket for the next request/response). And, of course, there's state in the sense of "I've read a partial request [or sent a partial response], now I have to read [send] the rest", but that is a rather different sense. But there are probably a few for which the request and response are self-delimiting. I couldn't think of any offhand; on looking at /usr/src/etc/inetd.conf, I see identd and not much else. There are others whose requests are a single line, such as finger, but, in all the cases I see, the response is not self-delimiting and thus requires either at least a tiny bit of additional protocol (and a daemon designed for it) or a new socket for each request/response (and thus either additional protocol or a new process for each request). On the question of "is it good" instead of "is it possible".... Plenty of such servers may exist in the wild. But are any of them used heavily enough that the code complexity of preforking is worth bothering with? I would guess (and a guess is all it is) that they are rare enough to handle them the way HTTP is often handled, with a long-running daemon (which, since it often isn't execing, can easily use a preforked pool of processes). I'm also not fond of inetd getting as complicated as these imply. /~\ 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
