On Fri, 2005-05-27 at 09:24 +0200, Thomas Mueller wrote: > Geo Carncross wrote: > > > 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. > > In Germany (afaik everywhere in Europe) time can go backwards: we have > normal time and summer time, UTC+1 and UTC+2 - so time does an one hour > backward jump once a year.
Daylight savings is common, but that's not what I mean. What I mean is if the UID is time-dependant, then whatever clock generates UIDs cannot go backwards. > Every host needs a GUID provider (without Pid/Tid in the GUID two > processes could get the same GUID otherwise), that could take care that > GUIDs are always increasing, the problem is synchronizing hosts. > I like your token ring idea, but please keep in mind that two dbmail > hosts don't have to be in the same LAN, for redundancy they could be > separated more. So passing a taken would take quite long. No, if the GUIDs are generated from a clock, then this won't ensure that GUIDs are always increasing. To reiterate from previous emails: What if one of the provider's clock runs fast? Runs slow? What if a GUID occurs from a previous epoch? -- Internet Connection High Quality Web Hosting http://www.internetconnection.net/
