<snip: question to explain fast/slow clocks> >> If all servers in the cluster are synced with a remote >> NTP >> server periodically I can't see how this would happen. >> This could just be a requirement of clustered >> multi-master >> systems. > > Let's keep it simple. Two machines, one is configured to > generate odd > sequence numbers and the other to generate even ones. > > So when one wants to write a message, it picks the > timestamp up, > discards or sets the ones-bit as necessary, and writes it. > > A 010 > B 011 > A 100 > B 101 > A 110 > B 111 > > Now, these show perfect sync for clocks on "A" and "B". > But let's say > "B" speeds up by "just a little bit" and we'll see. > > A 010 > B 011 > B 101 > A 100 > > Note in this case, "B" got it's message in before "A", but > with a higher > sequence number. This must be avoided because this breaks > RFC2060. > > Note: even if the clocks are sync'd, maybe one machine is > slightly > faster, or the network is slow. Any of a dozen reasons can > cause a delay > in packets. Thanks for the explination I totally understand now.
That being said, what is the actual harm in one message id being even a second off for the UID. They will both be entered in the mailstore, even if they are slightly out of order. Ultimately the Mail client will sort by the header information and if the clocks are different then they will be out of order. I should note that I've been running a Cyrus system for some time now that occasionally has messages arrive one or two spots out of order, due to latency with mailfilters. It really isn't a problem. I realize this might bend the RFC slightly... but the added functionality is great and it will not break any mail clients. I am all for complete RFC compliance, but if we are talking about a matter of a second here and there due to processor lag I think we are probably going overboard. I only put this thought out there so that it is out there. If we can come up with a "perfect" solution that is in fact doo'able within a reasonable timeframe lets go with that. > > You'll note I don't mention what these clocks are- > minutes, seconds, > milliseconds, or hours or something else (ticks?). > > That's because it doesn't matter: Whatever the quantum is, > whatever the > epoch size is, it's ALWAYS going to be possible for one to > just "come > in" before the other. > > -- > Internet Connection High Quality Web Hosting > http://www.internetconnection.net/ > >
