Re: rfc: gnome-inetd

[Alan Cox <alan lxorguk ukuu org uk>]

On Mer, 2004-12-01 at 01:37, Sean Middleditch wrote:
> The idea is that there are a list of commands port in GConf.  The daemon
> reads these and listens on the ports - when a connection comes in it
> launches the command, redirecting standard I/O to the new process.  Just
> like inetd, for the most part.

Sounds sensible to me. It also offers a chance to implement one thing
the inetd folks didn't realise in time to fix history - a port that says
what is listening.

> Best of all, because this is managed by GConf, administrators have
> control.  They can mandate that some services are always on (desktop
> sharing, which admins probably use the most) and others are always off.
> Configuration dialogs for various services would simple mark an enabled
> or disabled flag for services for users to turn them on and off (if they
> are allowed to).

And you can integrate it with firewall products. All of a sudden
questions like "remote audio" get easier.

> around is the potential performance problem.  Spawning new processes for
> each new connection can be fairly heavyweight.  Fortunately, desktop
> services don't usually serve a large number of users, and many of the
> interesting protocols don't need a lot of reconnecting (even for things
> like web sharing, browsers tend to reuse existing connections these
> days).

xinetd gets around this a variety of ways. For TCP it allows a daemon to
start up and be passed the socket. In essence for a given port it does

top:
	bind
	listen
	select
	Ah data
		fork
			exec
			child takes over
		parent:
			close
	...
	SIGCLD
		goto top

The java folks do much the same in the J2ME world and for similar
performance reasons.