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