Unique identifiers are assigned in a strictly ascending fashion in the
mailbox (See rfc2060).
The scheme of having dbmail pick one isn't conforming.
I recommend a XID-extension. Works in every way like UID except:
1. ranges aren't allowed
2. XIDs are opaque
UIDs make clients simpler, but they don't scale.
The clock idea would work if the clocks could be kept synchronized, but
that's just not possible. It's very hard work to get machines on a LAN
synchronized within 10msec, and clocks can NEVER go backwards. Not even
a little bit or mail will be lost until UIDVALIDITY changes or their
clients are reinstalled.
No matter how big you make your epochs (1 second, or 5 minutes like
kerberos does), it's possible and actually very likely that a message
will come in for the previous epoch and nobody will notice except the
angry mailbox owner.
On Thu, 2005-05-26 at 21:59 +0000, Aaron Stone wrote:
> 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
> >
--
Internet Connection High Quality Web Hosting
http://www.internetconnection.net/
