Add Universally Unique IDentifier (UUID) support#1015
Add Universally Unique IDentifier (UUID) support#1015eduard-bagdasaryan wants to merge 31 commits intosquid-cache:masterfrom
Conversation
Since the standard (RFC4122) guarantees uniqueness for these IDs, they can be safely used as various identifiers across all Squid instances and kids within one Squid deployment. The implemented UUID creation algorithm is based on random numbers generation, conforming to RFC 4122 Section 4.4.
|
FYI: we plan to utilize these new IDs as Vary identifiers in an upcoming PR. |
rousskov
left a comment
There was a problem hiding this comment.
Please also review my PR description edits and adjust further as needed.
by always converting them to network byte order. Also check during deserialization whether the passed bytes represent a valid version 4 variant 1 UUID.
eduard-bagdasaryan
left a comment
There was a problem hiding this comment.
Addressed the review requests (5068a70).
We cannot get rid of a local random_device variable because it is passed by reference to mt19937_64 constructor.
There are some concerns that this object may consume some system resources - so it looks better to construct it each time instead of keeping it in a static variable.
rousskov
left a comment
There was a problem hiding this comment.
Thank you for advancing this PR. I believe I found one bug to fix.
I would also like to request the addition of CppUnit tests that check uniqueness (to a very limited extent possible) and serialization/deserialization. Here are (very) rough sketches:
RandomUuid() != RandomUuid();There is a tiny risk a correct implementation fails this test, but I think we can and should take that risk in "make check" in this exceptional case. Moreover, I would not be against testing that the first 1000 or so generated UUIDs are unique.const RanomUuid uuid; RanomUuid(uuid.serialized()) == uuid;ToSBuf(RanomUuid(knownSerializedValue)) == textRepresentationOfTheKnownSerializedValuewhere knownSerializedValue is a valid hard-coded value you have observed in your tests and textRepresentationOfTheKnownSerializedValue is its hard-coded printed representation (stored as an SBuf string). You will probably need to hard-code knownSerializedValue by giving Serialized constructor 16 integers (one per byte).try { RanomUuid(allZeros); ... } catch { ... }where allZeros is a hard-coded Serialized array with all bits set to zero; look for the "should be rejected" string in src/tests/testCacheManager.cc for an example of how this "negative" test can be donetry { RanomUuid(allOnes); ... } catch { ... }where allOnes is a hard-coded Serialized array with all bits (not bytes) set to one; another "negative" test
* set correct bits in TimeHiAndVersion * do not call serialize() recursively
following a PR request
This reverts commit 12882c1.
* Serialize all multi-byte fields in network byte order to make identical string representation on different plantforms * Fixed a bug in timeHiAndVersion field * Added more unit tests
Done at 778b1aa. |
... to be high enough for bit manipulations in RandomUuid constructor to result in no significant effects on UUID uniqueness: 1) We concatenate two 64-bit random values to produce one 128-bit value, effectively halving std::mt19937_64 generation period (2^219937-1). If my math is right, it would still take ~2^9913 _years_ to generate P/2 UUIDs while generating one UUID per nanosecond! 2) We drop/ignore 6 of those 128 random bits at specific positions (occupied by UUID version/variant metadata) There is currently no Squid Project consensus whether these code manipulations decrease, increase, or leave unchanged any important qualities of the generated UUIDs. There is only consensus that the generated UUIDs will be of high-enough quality.
rousskov
left a comment
There was a problem hiding this comment.
Thank you for addressing my concerns. I hope we can fix the build without significant changes. I plan to clear this for merging after the build is fixed.
@yadij, there have been a few polishing changes since your last comment on this PR, so you may want to take a look before this goes in.
These 128-bit UUIDs have a very high chance of being unique across SMP Squid kids and even across independent Squid instances. Our UUID creation algorithm uses random number generation as described in RFC 4122 Section 4.4 (UUID version 4 variant 1).
These 128-bit UUIDs have a very high chance of being unique across SMP Squid kids and even across independent Squid instances. Our UUID creation algorithm uses random number generation as described in RFC 4122 Section 4.4 (UUID version 4 variant 1).
These 128-bit UUIDs have a very high chance of being unique across SMP Squid kids and even across independent Squid instances. Our UUID creation algorithm uses random number generation as described in RFC 4122 Section 4.4 (UUID version 4 variant 1).
These 128-bit UUIDs have a very high chance of being unique across
SMP Squid kids and even across independent Squid instances.
Our UUID creation algorithm uses random number generation as described
in RFC 4122 Section 4.4 (UUID version 4 variant 1).