Re: UUID

From: Richard Damon (Richard_at_[hidden])
Date: 2021-07-29 04:48:24

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 <boost-users-bounces_at_[hidden]> on behalf of
> Richard Damon via Boost-users <boost-users_at_[hidden]>
> *Sent:* Thursday, July 29, 2021 3:32 AM
> *To:* boost-users_at_[hidden] <boost-users_at_[hidden]>
> *Cc:* Richard Damon <Richard_at_[hidden]>
> *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_at_[hidden]
> > 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_at_[hidden]
> >     https://lists.boost.org/mailman/listinfo.cgi/boost-users
> <https://lists.boost.org/mailman/listinfo.cgi/boost-users>
> >
> >
> > _______________________________________________
> > Boost-users mailing list
> > Boost-users_at_[hidden]
> > 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_at_[hidden]
> https://lists.boost.org/mailman/listinfo.cgi/boost-users
> <https://lists.boost.org/mailman/listinfo.cgi/boost-users>

-- 
Richard Damon