Re: transports directory

[Tom Samplonius <tom@uniserve.com>]

On Thu, 6 Jul 1995 Nicholas_Briggs.PARC@xerox.com wrote:

> It's not absolutely necessary, but it simplifies things somewhat.   You should
> read the code rather than the ZMOG.   While it might not be very difficult to
> eliminate one or the other, it is not *necessary* to do so, and is likely to
> result in more problems than it is solving (what problem are you trying to
> solve??).   If you have time on your hands, and want to do something to

  Reduce I/O requirements.  From various reports, Sendmail puts less 
demand on system's disk I/O than Zmailer does, handling the same volume of 
mail.  It is easy to see why.  Sendmail, upon receipt of a message, saves 
a control file and a message file in the queue, and when the message has 
completed delivery, they are removed.  Zmailer saves the message file in 
the public directory, then moves it the router directory, then the router 
moves it to the queue directory and writes a control file in the 
scheduler directory.  The scheduler moves the control file into a channel 
directory and makes a link into the transports.  As you can see, a fair 
bit more disk activity.

  There was a discussion of this on this list some time ago, about disk I/O 
and Zmailer vs Sendmail.

> zmailer, IMHO it would be better spent reading and understanding the code and
> looking for bugs, security holes, performance problems, etc.  rather than
> making what sound like gratuitous changes to working parts of the system.

  I've been doing this.  Right now the major weak area, appears to be the 
scheduler.  It has a memory leak (I had 13M scheduler process once).  Now 
this is with the 2.99.X code, but little seems to have changed in this 
area.  The scheduler should likely be rewritten with a higher system 
standard (ex. os _must_ have select()).

> Sorry if this sounds somewhat curt, but I don't think change for change's sake
> is a good thing in software -- if there's a problem, solve it, if not, ...

  This is most definitely not for "change's sake".  I think that 
shortening the path of message through Zmailer is a good idea.  Right 
now, the current message flow seems to be unnecessary complexity.  If the 
scheduler is to be re-written, it would probably make sense to go to a 
simpler design.

  I'm not suggesting that the old scheduler to be hacked 
to do this.  In fact if it was, it would probably cause massive 
instabilities in the current scheduler that would take longer to debug 
than a re-write.

  To get an idea of where I going with this, I'd like to see the router 
and scheduler use a more advanced form of process communication rather a 
shared directory.  Perhaps sockets, and just use the directory queues as a 
fallback if a process becomes unresponsive (somewhat like the operation 
or rnews on a INN system:  if it can't pass the articles directly to 
innd, queue in a incoming directory).  However, I'd be the first to admit 
that this is long way off, if it is going to happen at all.

Tom