Sheldon and myself have been looking at the wrapping support in inetd, and
I'd be interested to hear what people think on the following issues.
David.
Making wrapping a run time option:
It seems strange to make wrapping a compile time option,
when it could be a command line option, or a per service
option in inetd.conf? I'd suggest that we have two command
line options, one which disables wrapping all together and
one which disables it for internal services.
Wrapping dgram services:
If our inetd wrapping is to replace tcpd we need to be able
to wrap the initial connection to udp based services. The
man page should make it clear that it can only check the
first connection to the service, and after that the service
is on its own.
An interesting question is, should we try to do this in a
clever fashion, or should we stick with something simple.
The simple implimentation looks like:
fork(); if( rejected ) exit() else provide_serivce();
The clever implimentation would look like:
fork; while( rejected && !timedout ) { get new packet };
if( timedout ) exit() else provide_service();
The clever one reduces forks, but as inetd isn't the place
where high performance services are provided from the extra
complexity may not be worth it.
Making internal services cleverer if they have forked:
If an internal udp service has forked it could provide its
service using a similar loop to the one for clever UDP
wrapping. This would reduce the amount of forking. Is it
worth the extra complexity?
Trying to wrap stream/wait services:
Doing this would involve being able to find the address of
the next connection on a listening socket without calling
accept. AFAIK this isn't possible with the normal socket
interface, and isn't supported by tcpd. We should probably
just say this isn't possible in the man page?
Wrapping of weirder types:
According to the inetd man page we support sockets of type:
``stream'', ``dgram'', ``raw'', ``rdm'', or ``seqpacket''.
I (personally) have never seen any inetd services using
raw, rdm or seqpacket - is it worth providing wrapping for
these socket types?
Adding wrapper support to "wait" daemons:
Daemons that use the "wait" class can only have their first
successful connection wrapped by inetd, and then they are
free to accept or reject subsequent connections themselves
until they exit. Usually they have a timeout (identd,
talkd), or only serve one connection (tftpd, rpc.rstatd).
Should we go around and try to add wrapper support into
these services?
To Unsubscribe: send mail to majord...@freebsd.org
with "unsubscribe freebsd-hackers" in the body of the message
