On Fri, Jul 22, 2005 at 01:19:47PM -0400, Mordechai T. Abzug wrote: > > Won't work. A client that performs the following operations will lose > > email: > > > > * Client (C) connects to host (A) sees uidvalidity mismatch; gets 1,2,4 > > * C connects to host (B) sees exists "4", tries to fetch uid 5, fails. > > > > The problem is that "B" really has uids "1,2,3,4" but the client saw a > > "gap" at "3" and will never download "3". RFC2060 _recommends_ clients > > perform this optimization, and many clients do. > > 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. > The reason I keep worrying about duplicates is that you have a > potential problem where email with UID 3 arrives at B, and UID 4 > arrives at A. If replication is delayed, the user could connect to B > and read 3, and then connect to A and read UID 4. When replication is > fixed, A receives a message about UID 3, realizes it didn't have it at > the time the user read UID 4, and updates the UID of 3 from 3 to 5. > The user connects again, and is told that there is a new message -- > UID 5 -- which is really UID 3 all over again. This can be mitigated > by running load balancers with user affinities. So long as the user > stays at one server, the user will always receive ALL mail, and will > never see duplicates. If that server goes down and the user switches > to another server, duplicates can result. Even if you have an affinity between IMAP client and server, there will also be SMTP servers potentially injecting messages into multiple database servers. xn
