On 29/07/2021 9:16 am, chengm349 wrote:

so boost uuid can't support compromised uuid needs?

Don't make something look like a uuid if it's not actually a uuid. That road leads to pain and torment. Go back to the customer and clarify the requirement, it's likely they can be persuaded to do things better.

On Thu, 29 Jul 2021 at 07:27, Ming Cheng via Boost-users < boost-users@lists.boost.org> wrote: Now let's focus on 64-bit UUID.

There is no such thing. Can do by boost?

Therefore no. As I mentioned before, let me hold responsible for mis-usage. you

experience people just help.

------------------------------ *From:* Boost-users on behalf of Gavin Lambert via Boost-users *Sent:* Thursday, July 29, 2021 3:07 AM *To:* boost-users@lists.boost.org *Cc:* Gavin Lambert *Subject:* Re: [Boost-users] UUID

On 29/07/2021 9:16 am, chengm349 wrote:

...

so boost uuid can't support compromised uuid needs?

Don't make something look like a uuid if it's not actually a uuid. That road leads to pain and torment.

Go back to the customer and clarify the requirement, it's likely they can be persuaded to do things better. _______________________________________________ Boost-users mailing list Boost-users@lists.boost.org 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

-- Richard Hodges hodges.r@gmail.com office: +44 2032 898 513 home: +376 861 195 mobile: +376 380 212

The Boost UUID class only handles 128 bit UUIDs. So it won't help you. There may be other Boost Libraries that might be of use to implement whatever you choose to use. You might be able to look at the implementation of the Boost UUID library for ideas, but I am not sure if it will really be useful. It sounds like YOU (or your customer') need to define exactly what this 64-bit 'UUID' will be defined as, and what it is capable of. You will definitely need to solidify how you are going to define how your UUID is built. 'Random' UUIDs at 64 bits have a moderate chance of getting collisions depending on the exact usage pattern, and how much problems collisions create. Non-Random UUIDs require some form of unique Host ID that uses some of the bits, that you need to decide how that is to be handled. 'Randomly' generating the Host ID, has issues of keeping them unique, and may need more bits than you want to spend out of your 64 bits than you can afford to spend. On 7/28/21 9:53 PM, Ming Cheng via Boost-users wrote:

It's a very very big exchange. I don't think I can persuade it to change(?). Now let's focus on 64-bit UUID. Can do by boost? As I mentioned before, let me hold responsible for mis-usage. you experience people just help.

------------------------------------------------------------------------ *From:* Boost-users on behalf of Gavin Lambert via Boost-users *Sent:* Thursday, July 29, 2021 3:07 AM *To:* boost-users@lists.boost.org *Cc:* Gavin Lambert *Subject:* Re: [Boost-users] UUID   On 29/07/2021 9:16 am, chengm349 wrote:

...

so boost uuid can't support compromised uuid needs?

Don't make something look like a uuid if it's not actually a uuid.  That road leads to pain and torment.

Go back to the customer and clarify the requirement, it's likely they can be persuaded to do things better. _______________________________________________ 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

-- Richard Damon

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

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

-- Richard Damon

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