Re: alternatives to ETRN

[Matti Aarnio <mea@nic.funet.fi>]

Matus Uhlar wrote:
... (ETRN talk removed)
> I even thought about mail processing. NROUTERS is defined in
> /etc/zmailer.conf and contains number of routers running. I thought this
> number could be sometimes too big and someties too low on the same machine.
> Wouldn't it be better to make it virtual ?
...
> Maybe there should be main router listening on named pipe for
> smtpserver/sendmail which will only take incoming messages, put them to
> files (or will take just filename) and execute child routers which will
> process those messages. And it can have x to y child routers processing
> those messages (x and y defined in config file). comunications between them
> could go through unnamed pipe, and router will know when it should create
> new router (too much unprocessed messages in incoming queue) if it shouldn't
> fork (too big load average or too much routers running), if it should kill
> one of its childs (2 childs idle for given time) etc. 
> 
> I know this is just speculation but maybe will give you (Matti) good idea.

	Perhaps.  I do have thought of it, but not done anything for it.
	Like with scheduler, the router needs to collect new jobs, and
	then process them.

	The way things work now, is to run a fixed size of set of router
	processes all competing with each other on which job-file to pick.
	If there would be a job-feeder master in scheduler style, it could
	spot new jobs arriving (thru UDP/AF_UNIX/whatnot IPC mechanism, and/or
	plain directory scan every now and then), and add them into the queue,
	then to run a farm of router sub-processes feeding each with a new
	job-spec in similar style to that of the scheduler/transport-agent
	interface is:

		master:
			create bidirectional pipe, fork slave
		slave:
			start main job-acceptance loop; send
			"#hungry\n" message to master
		master:
			Notice appearance of "#hungry\n", and
			feed job filename: "12345\n"
		slave:
			pick job filename, do the processing,
			and report for more work ("#hungry\n").
		master:
			... loop continues ...

	Things will become more complicated, when the queue processing
	wants to do also router resource management, for example by
	starting up additional working routers, if the queue is long,
	and to cut down the number of routers, when there is no more
	work, and they have been idle for some preset time.

	Would somebody want to do such code ?

> e.g. when smtpserver gets expn or vrfy, executes router with one command -
> router <addr>; it could also use named pipe 

	Not so easy at all.
	The number of needed named pipes, and routers behind them
	is not easy to predict.

	Also security issues might greep up -- router process runs with
	root privileges, and the current smtpserver/router interface is
	essentially a bidirectional pipe thru which a set of shell commands
	is sent down to the router, and responses are read by the scheduler.

> -- 
>  Matus "fantomas" Uhlar, sysadmin of one server at SANET Kosice, Slovakia
>  E-mail: Matus.Uhlar@tuke.sk ; WWW: http://ccsun.tuke.sk/users/uhlar

/Matti Aarnio <mea@nic.funet.fi>