[dovecot] Re: Architectural questions

[Thomas Wouters]

On Tue, Oct 22, 2002 at 05:31:22AM +0300, Timo Sirainen wrote:
> On Tue, 2002-10-22 at 04:24, Timo Sirainen wrote:
> > Just had a thought. Would it be feasible to _try_ to permanently assign
> > users to one or few specific servers (via ip or maybe login proxy)? If
> > those servers were down, it could fallback to any random one.

Yes, the Alteons we use can be configured quite flexibly. We can easily
configure, e.g., two servers as 'primary' and two fallback servers, or do
load-balancing based on the output of a script, or any number of things. We
only use the general load-balancing (actually just
active-connection-balancing) while keeping sessions on the same server
(based on remote IP) but we could look into the more intricate methods. A
single IMAP server with a backup is a good start though.

> Dovecot could actually do that itself too, authenticate user and then
> either locally handle it or transfer it to another node based on some
> configuration.

You mean if you have a frontend with several backends, and the frontend
proxies for the backends (with several frontends possible, for redundancy,)
hmm, that might work. Diablo (the news server software) works like this,
somewhat, too, and we also use it behind Alteon switches :)

> > I really like this idea, keeping indexes in local disk where they may be
> > considered as fast non-permanent data and then reading the actual mail
> > data via backed up NFS server. This gets me thinking of a lot more
> > possible optimizations to reduce NFS I/O at the cost of more local.. :)

> This again makes the indexer process possible and useful, since it would
> be accessing only local disks. It could also delete some of the older
> indexes if disk space is getting full.

Yes. Keeping things on local disk sounds good. As long as opening the same
mailbox on another server doesn't break anything (or breaks 'cleanly',
doesn't delete the wrong mails etc) we can definately live with much worse
performance for those cases. My professional estimate is that they will be
very, very rare ;P

But for the time being we're more concerned with the SORT extention :) I've
read the spec, and besides the natural "ugh" at having to parse the subject
that way, it seems doable... except that charset support for UTF-8, as well
as US-ASCII, is mandatory. I don't know any libraries that convert to/from
UTF-8 (though ASCII<->UTF-8 is obviously simple :) and though it's probably
easy to roll your own for iso8859-1 I'm not sure if you had a solution in
mind yet. Also, supporting the other character sets (like UW-IMAP does) is
probably a lot trickier.

Other than the charset issues I could probably whip up a working SORT
implementation given enough time... but it probably wouldn't be
super-efficient, as quicksort is so much easier to start with than, say,
a mergesort ;P

-- 
Thomas Wouters <thomas at xs4all.net>

Hi! I'm a .signature virus! copy me into your .signature file to help me spread!