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

Re: Reworking on smtpserver subsystems..

On Mon, 2004-04-05 at 19:49, Matti Aarnio wrote:

> > Now, smtpserver will inject jobs to the router farm over the socket, the
> > router pass it to the scheduler, again, over another socket, and
> > [scheduler] pass it to the transport agent much like it does now *but*
> > over the socket rather than pipe.
> Here I got a bit confused,  do you mean "pass the message file over
> the socket"  or just (as we already do with notifications), tell about
> new jobs available in the queue ?

I mean that the *file name* is (always) passed over between different
processors.  Like it is now (but this could become the *only* way to
inject a job, startup/periodical directory scanning being done

> > On reboot/restart, a separate ("run once") process can traverse queue
> > directories and inject old jobs emulating smtpserver for the router, and
> > another one emulating router for the scheduler.
> This is for the external persistent queue model.  Any further thoughts
> about how that persistency could be implemented ?

I suggest it for "internal" case as well.

> >  The only bottleneck continues to be the scheluler, but even that
> > will need half as many descriptors as it uses now.
> Half of one descriptor per transport agent is ...  integresting ;-)
> I think you have missed the quirks in  lib/pipes.c  (formerly in
> scheduler/pipes.c);  when ZMailer is being compiled in a system with
> socketpair(2) call, it will be used.  The fall-back will use classic
> pipe(2), that are unidirectional, and are needed in pairs.
> (Presumption is, that if the system doesn't have  socketpair(2),
> things are grim indeed...)

Guilty, Your Honor!
I was unaware that pipe() has been replaced with socketpair()

> > If sockets are used to pass queue object handles, then the current file
> > approach is quite easily extended to database approach, only interface
> > functions will change, not the "business logic" code.  Having queue
> > objects in a database would (theoretically) allow to keep queue on one
> > physical server, smtpserver on another, router on the third, etc.  All
> > of them would communicate over tcp sockets and access actual message
> > data via particular database API.
> Uh....  I do know that Oracle has a product doing something quite like
> what you describe, but would it  a) really make sense,  b) be lightweight
> enough to be worthwhile without huge server hardware ?

It just becomes theoretically possible.
And it *may* be еру way to scale the system up to the size of Yahoo
mail, if anyone would want to.


This is a digitally signed message part