Added "current modseq" parameter to all commands and MODSEQ command. Other things missing from the replication protocol are related to mailbox list, i.e. figuring out which mailboxes to replicate, which are newly created, deleted, renamed, etc. There will probably have to be a new "unique global mailbox ID" which is preserved across renames.
I think global message UIDs will also become 128bit IDs instead of 64bit. 128bit GIDs could be generated from:
- 64bit timestamp with nanosecond resolution (or microsecond if clock_gettime() not available). When delivering multiple mails within a process make sure this value increases always.
- 32bit process ID
- 32bit server ID (configurable? based on IPv4 address? 48bit MAC address by reducing PID/timestamp by 16bits? is exposing these to a normal user a security problem?)
I think it's pretty safe to assume that two processes can't deliver a mail within the same nanosecond using the same PID.
Modseq changing
MODSEQ:
- IMAP UIDs
- Updated modseq
When doing expunges, stores or whatever else in future updates modseqs, there's a problem with keeping them synchronized between all servers. This command allows fixing them so that the entire cluster will have the modseq from the server that assigned the highest modseq for the change. This means that some servers may temporarily assign a lower modseq for a message only to be soon updated to a slightly higher modseq.
When master is processing commands if a command's modseq parameter <= highest-modseq, the master sends back a MODSEQ which changes the message's modseq to highest-modseq+1. The command is forwarded to other servers using the updated modseq.
When server receives a MODSEQ command, the modseq is updated only for the messages which currently have a lower modseq. The modseq must be updated also if the message has already been expunged, so that syncing (replication or QRESYNC) can send expunges correctly.