Re: Unique ID

Agreed - the use of a timestamp, even out to microseconds, is no longer trustworthy as to uniqueness. And even the MI TOD value, which used to be documented to produce a unique value - it doesn't anymore - in the world of multiple cores. It used to report the clock ticks, which were every 8 microsecs - at 6.1 the resolution went to 1 microsec - even so, I've run tests that product the same value.

So this specification, well, I'm inclined to trust it until I see a reported problem - I looked up the spec (RFC4122) and find this interesting statement -

Since a UUID is a fixed size and contains a time field, it is possible for values to rollover (around A.D. 3400, depending on the specific algorithm used).


That should be enough for uniqueness, right? It doesn't depend on any particular machine architecture, so far as I can tell - this RFC comes out of the DCE work, which was a joint effort of companies like HP and IBM and others. So the TOD issues are not part of it, so far as I know.

The algorithms are listed in the RFC, viewable at http://www.ietf.org/rfc/rfc4122.txt

Of course, for short-term, other methods are needed - to get an object name, UUID won't work - it's 128-bits (16 bytes) and a character representation is 32 long.

Interesting stuff - for another day - but it can be trusted, I'm sure.

Vern

On 5/2/2012 6:19 AM, rob@xxxxxxxxx wrote:

Well, I clicked the link and I read
"The UUID is unique as an identifier across all time and space and is
consistent with the Open Systems Foundation (OSF) Distributed Computing
Environments (DCE) version 1 UUID specification described in the DCE's
"Architecture Environment Specification/Distributed Computing: for Remote
Procedure Calls", Appendix A."

Across all time and space sounds pretty darn unique to me.


Rob Berendt