On Fri, 2005-07-22 at 14:18 -0400, Mordechai T. Abzug wrote:
> On Fri, Jul 22, 2005 at 10:43:17AM -0700, Christian G. Warden wrote:
>
> > > The design actually ensures, in this exact scenario, that the client
> > > does see the mail. What happens is that when B creates email UID 3, B
> > > sends A a message saying "I made an email with UID 3". When A
> > > receives the message after telling the user that the last UID is 4,
> > > and since 4 is greater than 3, so A will MODIFY the UID in the
> > > database from 3 to 5. That change in UID will replicate back to B.
> > > After that correction, the next time the user connects to either
> > > server, the user will pick up the new email. Effectively, you have
> > > strictly increasing UIDs. See?
> >
> > Doesn't this assume that there is no latency in replication? When B
> > gets the message that 3 is now 5, B may have already generated 6, so 5
> > must now become 7. But when A learns that 5 is now 7, it already has an
> > 8, and 7 must become 9, ad infinitum.
>
> If B has generated 6, but the user hasn't yet read 6, and then B
> receives a message saying that A has generated 5, B won't renumber 5
> to 7. A server only renumbers if it hears about an old number after
> reporting a newer number to a user. If the user does happen to
> connect to B and read 6 before B hears about 5, then yes, B will
> renumber 5 to 7. But having this happen ad infinitum (ie. "thrashing"
> in the original message) requires the user to very quickly switch
> between servers, and a whole lot of new email to arrive at each
> server, faster than replication can keep up. This is not only
> unlikely, you can prevent it by using affinities.
If you have per-user host affinities that are _guaranteed_ then you've
gotten load-balancing (again) and not high-availability. You've just
moved the load-balancing onto an extra point of failure.
Nevertheless the problem still exists:
Client is fresh
Client connects to A and gets UID 1,2,3,4,5,7
Client connects to B and sees EXISTS=6
because B sees UID 1,2,3,4,6,7
Client will NEVER download "UID 6" because it doesn't know about it.
> > Even if you have an affinity between IMAP client and server, there
> > will also be SMTP servers potentially injecting messages into
> > multiple database servers.
>
> That's OK. Let's say an SMTP server injects a message with a certain
> UID X, and the replicated email and message eventually reach the IMAP
> server where the user is reading mail. Say the IMAP server has
> reported highest UID Y at the time the email arrives. If X>Y, no
> action is necessary. If Y>X, the IMAP server renumbers UID X to a new
> UID Z that is greater than Y, and the next time the user connects, the
> user finds out about UID Z. No "duplicate" email if the user connects
> to the same IMAP server; no email lost no matter what the user does.
No the email is lost because the client "thinks" the highest UID is "7"
but now connects to a machine where UID "6" is no longer a gap.
--
Internet Connection High Quality Web Hosting
http://www.internetconnection.net/
