Re: [Boost-users] UUID

You may want to look up the formal definition of a UUID in RFC 4122 or perhaps some of the various documentation on the web about them. Basically it takes the 128 bits of the UUID and breaks it up into bit fields with specific meanings based on the 'Type' of the UUID, and also reservse a few of those 128 bits to indicate what type/version this UUID was built with. For Type 1 UUIDs, basically 48 bits are filled with the MAC Address of the device (or a 47 bit random number with a specific bit set to 1 which no MAC address for an adapter will have set), 60 bits are from the time stamp, 6 bits specify that it is a 'Variant 1, Version 1' UUID (the normal Type-1 UUID, and  we have 14 bits left over for use as a 'clock sequence' that can be used however the host desires to make sure that all the values generated are unique (some bits might be used for thread/process id, some to allow more than 1 UUID being generated per 100 ns by a given thread). My thought was that BOOST had in its library the code needed to generate and save these UUIDs. On 7/28/21 8:57 PM, Ming Cheng wrote:

Hi Richard,

Thanks for your effort on explaining UUID in detail and possible way to try.  Let's focus on Type 1(T1) which could be possible. Seems T1's timestamp part if 64 bit and how to get its value?  Is it possible you can show some pseudo code? Let me worry about the rest.

Thanks, Ming

------------------------------------------------------------------------ *From:* Boost-users on behalf of Richard Damon via Boost-users *Sent:* Thursday, July 29, 2021 3:32 AM *To:* boost-users@lists.boost.org *Cc:* Richard Damon *Subject:* Re: [Boost-users] UUID   The biggest fact is that there IS an official definition of what a UUID is, and that is a 128-bit value, with a specific set of generation methods. (and I think that is what BOOST is supporting)

Note, that the 'Type 1' official format of UUID do use 60 bits of the UUID from a time stamp with 100ns precision, and combine that with 40 bits that uniquely identify the host (its MAC address), and additional bits to handle identify the type of the UUID and to allow the host to make sure that every UUID it makes are unique, even if it might make more than 1 per 100ns. This format actually guarantees that (if the host does its job) that there will NEVER be a duplicate, but does require the unique MAC address.

Depending on the use, going off definition might be ok, but one key factor is how it is going to be used.  64-bit values, IF you have a method to make the selection of values at least fairly uniform (which time stamps most definitely are not) then the expected number of how many you can 'randomly' generate before getting a repeat is abut 2^32. Depending on how bad of an effect you expect from a duplicate, that says that 64-bit 'random' UUID shouldn't be trusted for much more than some number of million ID in the life of the system (or at least the period that duplicates matter).

If the 64 bits can be divided into parts, with some number of bits being a unique identification of the system, and the rest being generated by the system in a way that it can make sure are unique, then 64 bits could easily be enough for many applications. This does require a central authority to distribute system ID, the official UUID got this via the MAC Address which most system that need UUIDs will be network connected and thus get a MAC Address, so they could borrow that central authority.

The question comes is the 'cost' of being non-standard less than the savings of dropping the UUID from 128-bits to 64-bits.

On 7/28/21 2:19 PM, chengm349--- via Boost-users wrote:

...

how about 64-bit value if we ignore timestamps only part recommendation?

Sent from my Huawei Mobile

-------- Original Message -------- Subject: Re: [Boost-users] UUID From: Richard Damon via Boost-users To: boost-users@lists.boost.org CC: Richard Damon

     On 7/27/21 11:34 PM, Ming Cheng via Boost-users wrote:      >      > I have a UUID requirement as:      >      > * Each session will also be represented with a Universally Unique ID      > (UUID), which should be a current timestamp      > * a unique UUID value set by the customer as a 64-bit value. CME      > Group recommends using the system timestamp which represents the      > number of microseconds since epoch (Jan 1, 1970) as the timestamp.      > * I also need to save it in a Linux file and rebuild the UUID from      > the saved value.      >      > Wondering whether boost UUID code can support it?  I checked online      > document and seems to me quite difficulty except archiving.      >      My first thought is someone doesn't know what a UUID is. 'The Current      Timestamp' is NOT a UUID, and the chance of duplicates is going to be      reasonable high if sessions might be started on multiple machines at      about the same time.

     --      Richard Damon

     _______________________________________________      Boost-users mailing list      Boost-users@lists.boost.org      https://lists.boost.org/mailman/listinfo.cgi/boost-users https://lists.boost.org/mailman/listinfo.cgi/boost-users

_______________________________________________ Boost-users mailing list Boost-users@lists.boost.org https://lists.boost.org/mailman/listinfo.cgi/boost-users https://lists.boost.org/mailman/listinfo.cgi/boost-users

-- Richard Damon

_______________________________________________ Boost-users mailing list Boost-users@lists.boost.org https://lists.boost.org/mailman/listinfo.cgi/boost-users https://lists.boost.org/mailman/listinfo.cgi/boost-users

-- Richard Damon