[Raw Msg Headers][Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Reworking on smtpserver subsystems..



My thoughts on this matter are as follows:

- Forking model should be Apache-like, with preforked processes that can
be reused up to N times.  In border case, you may have zero preforked
servers and N=1, which gives one forked process per session.  Normally,
you can have a pool of no more than MAX processes preforked and ready to
serve.  This approach is very portable, efficient and does not suffer
from problems inherent to thread model.

- All elements (smtpserver, contentfilter, router *and* scheduler with
transport agents) should use same technology of process management and
interprocess communication.

- You will need queues on persistent storage anyways.  Let's think that
queue objects are files on the local filesystem.  The object handle will
be path (thus an ascii string).  This is easily extendable to the queue
kept in a database.  So the elements of the MTA will pass each other
queue object handles.

- Initial processing of existing queue after restart/reboot can be done
by a separate tool, so no need to scan directories from router/scheduler
processes.

- Data access should be kept separate from processing management.  I
mean, queue object should be opened as a file or retreived from a
database, while the *handle* (e.g. path to the file) passed over sockets
or whatever.  Actual data never is passed over IPC.

- Use sockets for IPC, not doors/shm/whatever.  Normally unix domain
sockets (but if the queue is in a database that may be TCP).  Sockets
are the most portable of all IPC means.

Eugene

-
To unsubscribe from this list: send the line "unsubscribe zmailer" in
the body of a message to majordomo@nic.funet.fi