[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Re: inetd tests failing
>> 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 mouse%rodents-montreal.org@localhost
/ \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B
Main Index |
Thread Index |