So that's cool just the pid and pid-sequence would need to be padded to maintain the sequence.
right? > > 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 <dbmail-dev@dbmail.org> > To: "DBMAIL Developers Mailinglist" > <dbmail-dev@dbmail.org> > 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 >> > Dbmail-dev@dbmail.org >> > http://twister.fastxs.net/mailman/listinfo/dbmail-dev >> > >> >> _______________________________________________ >> Dbmail-dev mailing list >> Dbmail-dev@dbmail.org >> 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. > -- > > _______________________________________________ > Dbmail-dev mailing list > Dbmail-dev@dbmail.org > http://twister.fastxs.net/mailman/listinfo/dbmail-dev >
