I think an important question to ask is how many messages we really want to be able to fit into a mailbox. IMAP's 32 bit limit, and that some clients treat those 32 bits as signed (is this true? do we need to worry?), indicates that there's already a limit of 2 billion messages per mailbox.
If we're comfortable with a limit of, say, 16 million messages per mailbox, then we can go with 24 bits incrementing, 7 bits server id, and 1 bit lost. 2^24 == 16,777,216 60 sec * 60 min * 24 hours * 365 days == 31,536,000 Unfortunately, 24 bits will only hold about 6 months worth of seconds. Using UNIX time only gives us until 2038 before we're screwed; and that's if there's one message per second. Using a time window could help with this, which is what I think Paul might have mentioned in a previous email: next_uid = (curret_time - mailbox_time) By subtracting the mailbox's creation time from the current time, we effectively restart the sequence, and, in a weird way, we give each mailbox about 50 years to live from the time of the mailbox's creation. If we do this: next_uid = (curret_time - mailbox_time) (24 bits) . server id (7 bits) Then the mailbox only has 6 months, with a cluster of 128 machines. next_uid = (current_time - mailbox_time) (27 bits) . server id (4 bits) Then the mailbox has 5 years to live, with a cluster of 16 machines. next_uid = (current_time - mailbox_time) (29 bits) . server id (2 bits) Then the mailbox has 17 years to live, with a cluster of 4 machines. --- Sadly, it's looking like 32 bits is just too small to combine time with anything else. We could go to a keyserver architecture, where there's one machine that has the task of doling out the next keys, which means we would be bound not by time but by the number of messages, but it also means that we'd lose significant clustering flexibility. *** Why isn't the a spec for 64 bit IMAP ids yet?! Should we write one? Aaron On Thu, May 26, 2005, ""Kevin Baker"" <[EMAIL PROTECTED]> said: >> Geo Carncross wrote: >>> On Thu, 2005-05-26 at 13:49 +0200, Paul J Stevens wrote: >>> >>>>Ok, let me recapitulate: >>>> >>>>- we want to replace all auto-incremented fields with >>>> bigint fields to >>>>hold uuids in order to accomodate N-clustered databases. > > So the problem seems to be generating a sequential 32bit > char based on time and server id. > > I'll have to do some reading on 32bit chars... to get my > head around this... > > > Kevin > > <snip: comments that seem to go over stuff from last years > thread> > > _______________________________________________ > Dbmail-dev mailing list > Dbmail-dev@dbmail.org > http://twister.fastxs.net/mailman/listinfo/dbmail-dev > --
