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. > 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. - Morty
