On Fri, 2005-07-22 at 15:43 -0400, Mordechai T. Abzug wrote:
> > 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.
>
> No. *Initially*, server B has a message with UID 6 which the client
> won't download. But replication keeps going. The email with UID 6 is
> replicated to A. The message from B to A saying it created UID 6 is
> replicated to A. So Server A learns about UID 6. Then this scheme
> kicks in: server A says "oops, I didn't know about a UID 6 when the
> client downloaded 7", and reassigns the email a new UID -- say, UID 9.
> That change, in turn, is replicated back to B, along with a message
> that says A created 9. B has the UID 9 email, and can ignore the
> message if the client hasn't downloaded any newer emails. Next time
> the client connects to either A or B, the client sees a new UID (9).
> So the email, originally UID 6, is not lost, it's just assigned a new
> UID.
I understand what you're saying about duplicates now. You're saying,
worst case scenario, UID 6 is downloaded twice- once as UID 6 and the
second time as UID 9.
Note: "B" however cannot ignore that message. It _MUST_ rewrite it. It's
not acceptable for UID 6 to refer to a different message on each host.
After that replication, a request for UID 6 must fail.
Also note that this lowers the effective number of messages per mailbox
pretty quickly. a UIDVALIDITY change could be needed as quickly as 1.5
million messages on a 64-node dbmail cluster. I have a few mailboxes
that large. A two-node dbmail would be sufficient for most, and "only"
support about half a billion messages. Someone with a billion messages
can suffer if they're using IMAP still...
The good news is that this system is a lot simpler than your mechanism.
You can implement it as an IMAP client and DBMAIL needs to know nothing
about it (except one point!)
The client logs into two IMAP servers, and foreach message on each host:
FETCH 1
APPEND 2
STORE 1 +FLAGS (\Deleted)
EXPUNGE
FETCH 2
until the UID numbers match. DBMAIL would need that to be a "secret
expunge" that tells other clients that an expunge occurred (wake from
IDLE, etc) and only expunges "deleted messages" that were created during
this session, but those semantics are added easily.
It's a race though. Lots of UIDs are going to be wasted doing this if a
client makes any changes themselves.
That said, I think I like this idea.
It's less invasive than mine, but I think this will screw up several
clients. The question would be "how bad". I'm betting the worst would be
Outlook Express....
Fortunately, we don't have to use your original [published] algorithm to
find out. A simpler version can be implemented outside of DBMail, and we
can find out exactly how clients will react. Profiling that will tell us
exactly what hooks need to be put into DBMail.
--
Internet Connection High Quality Web Hosting
http://www.internetconnection.net/
