Hello, I actually meant to add a pid and per-pid sequence to the setup you put forth, so something like:
[YYYY][MM][DD][hh][mm][SS][ss][server-id][pid][pid-seq] All mapped to bits of course, as you only had 32 bits to put all this in (iirc). The scenario I was working to avoid was 2 messages being delivered within the same ms on the same machine (ie. same "server-id"). As you can have multiple processes on the same machine delivering simultaneously, using the pid will in practice likely take care of the problem, but you could throw a per-pid sequence in to just to be safe. I went through this same issue when messing with the pop3 unique_id stuff a year or so back (although I probably wouldn't have noticed the collisions if I had used ms resolution :). Jn ---- Original Message ---- From: Kevin Baker <[email protected]> To: "DBMAIL Developers Mailinglist" <[email protected]> Subject: Re: [Dbmail-dev] GUID vs Auto-incrementing... dev? Sent: Thu, 2 Sep 2004 09:48:58 -0700 (PDT) > I'd be concerned about using the pid. The pid on each > machine could be padded to different lengths causing the > numbers to be non-ascending between servers. > > With a machine id set in the dbmail conf we'd have control > over this. > > Example with pid: > > [YYYY][MM][DD][hh][mm][SS][ss][pid] > > if you had two messages arrive at the same time with a pid > of 123 on machine one and 95432 on machine two they would > be out of order and nonsequential. In addition it is very > unlikely, but the pids could be the same making the id > non-unique, thus non rfc. > > > The other way: > [YYYY][MM][DD][hh][mm][SS][ss][server-id] > > server one 0001 > server two 0002 > > So long as the ids are padded to the same length across > machines in a cluster the number would always be ascending > and unique. If messages did happen to come in at the same > time they would never collide, because of the padded > server-id suffix. > > [external-ip][YYYY][MM][DD][hh][mm][SS][ss][server-id] > > I like the idea of possibly adding a prefix to the id > though.. something unique to the email solution such as > the clusters external ip... this could also be set in the > conf pulled from the message header. This would actually > make the ids unique globally, while keeping the ascending > order. However by RFC they only need to be unique to the > mailbox(folder). > > > - Kevin > > > > > > I don't think so.. I'm pretty sure that the email client > > will just refresh the mailbox it is displaying.. messages > > are then sorted by message-id or other if in the view > > settings. > > > > We have had this happen in our current configuration cyrus > > as messages can sometimes get caught up in amavis running > > through filters for a second or so... they just appear and > > everthing is fine... > > > > > > > > > > <snip long text> > >> I'm not at all familiar with IMAP, would that cause > >> any > >> problems with imap clients, having "old" unique-id's > >> popping > > <snip> > >> "new" messages have what appears to be out of sequence > > > > _______________________________________________ > > Dbmail-dev mailing list > > [email protected] > > http://twister.fastxs.net/mailman/listinfo/dbmail-dev > > > > _______________________________________________ > Dbmail-dev mailing list > [email protected] > http://twister.fastxs.net/mailman/listinfo/dbmail-dev > -- End Original Message -- -- Jesse Norell [EMAIL PROTECTED] is not my email address; change "administrator" to my first name. --
