The UUID module uses network byte order, regardless of the platform byte order. On little-endian platforms like Windows the ".bytes" property of UUID objects is not compatible with the memory layout of UUIDs:
import uuid import pywintypes s = '{00112233-4455-6677-8899-aabbccddeeff}' uuid.UUID(s).bytes.encode('hex') '00112233445566778899aabbccddeeff' str(buffer(pywintypes.IID(s))).encode('hex') '33221100554477668899aabbccddeeff'
Ka-Ping Yee writes* that the Windows UUID generation calls are not RFC 4122 compliant and have an illegal version field. If the correct byte order is used the UUIDs generated by Windows XP are valid version 4 UUIDs:
parts = struct.unpack('<LHH8s', pywintypes.CreateGuid()) parts[2] >> 12 # version 4 ord(parts[3][0]) & 0xC0 # variant 128
The first three fields (32 bit time-low, 16 bit time-mid and time-high-and-version) are stored in the platform byte order while the remainder is stored as a vector of 8 bytes. The bytes property and bytes argument to the constructor should use the platform byte order. It would be nice to have explicit little endian and big endian versions available on platforms of either endianness for compatibility in communication and disk formats. There is another issue with version 1 uuid generation:
len(set(uuid.uuid1() for i in range(1000))) 992
The problem is that the random clock_seq field is only 14 bits long. If enough UUIDs are generated within the same system clock tick there will be collisions. Suggested solution: use the high-resolution of the time field (100ns) to generate a monotonically increasing timestamp that advances at least by 1 for each call, when time.time() returns the same value on subsequent calls. Oren [*] http://mail.python.org/pipermail/python-dev/2006-June/065869.html
On Thu, 3 Aug 2006, Oren Tirosh wrote:
The UUID module uses network byte order, regardless of the platform byte order. On little-endian platforms like Windows the ".bytes" property of UUID objects is not compatible with the memory layout
RFC 4122 says: In the absence of explicit application or presentation protocol specification to the contrary, a UUID is encoded as a 128-bit object, as follows: The fields are encoded as 16 octets, with the sizes and order of the fields defined above, and with each field encoded with the Most Significant Byte first (known as network byte order).
Ka-Ping Yee writes* that the Windows UUID generation calls are not RFC 4122 compliant and have an illegal version field. [...] If the correct byte order is used the UUIDs generated by Windows XP are valid version 4 UUIDs:
I see. I stand corrected, then. My interpretation of RFC 4122 would be that the uuid.py module currently completely implements RFC 4122; while Windows XP can't be said to violate RFC 4122, supporting this alternative byte order would be an optional feature.
The bytes property and bytes argument to the constructor should use the platform byte order.
I disagree; i think the main interface to uuid.py should behave consistently independent of the platform, and should conform to the default encoding in RFC 4122. However, we could certainly consider adding a 'bytes_le' field to support the functionality you describe. I'll ask Anthony whether adding such a field would be permitted at this stage of the release process.
There is another issue with version 1 uuid generation:
len(set(uuid.uuid1() for i in range(1000))) 992
The problem is that the random clock_seq field is only 14 bits long. If enough UUIDs are generated within the same system clock tick there will be collisions.
The clock field of the UUID has enough resolution to avoid collisions; the problem you're describing is a limitation of the platform's clock, not the UUID module. It doesn't happen on Mac OS X, for example.
Suggested solution: use the high-resolution of the time field (100ns) to generate a monotonically increasing timestamp that advances at least by 1 for each call, when time.time() returns the same value on subsequent calls.
That sounds like a fine solution to me. I'll look into it. -- ?!ng
On 04/08/06, Ka-Ping Yee <python-dev@zesty.ca> wrote:
On Thu, 3 Aug 2006, Oren Tirosh wrote:
The UUID module uses network byte order, regardless of the platform byte order. On little-endian platforms like Windows the ".bytes" property of UUID objects is not compatible with the memory layout
RFC 4122 says:
In the absence of explicit application or presentation protocol specification to the contrary, a UUID is encoded as a 128-bit object, as follows:
The fields are encoded as 16 octets, with the sizes and order of the fields defined above, and with each field encoded with the Most Significant Byte first (known as network byte order).
RFC 4122 defines a canonical byte order for UUIDs but also makes explicit reference to the fact that UUIDs are stored locally in native byte order. The final step in the RFC 4122 UUID generation algorithm is:
o Convert the resulting UUID to local byte order.
So this is not another case of the Microsoft-implements-RFC-incorrectly syndrome. After all, they are one of the co-authors of the document. Compatibility with Windows "GUIDs" may be one of the most important use cases for the UUID module. It's important to resolve this or users will have unpleasant surprises. I did. alternatives: 1. Default is big endian byte order. Little endian is explicit. 2. Default is native byte order. Little endian and big endian are explicit. 3. No default. Little endian and big endian are both explicit. All three are relevant for both the constructor and retrieving the byte representation. Oren
On Fri, 4 Aug 2006, Oren Tirosh wrote:
Compatibility with Windows "GUIDs" may be one of the most important use cases for the UUID module. It's important to resolve this or users will have unpleasant surprises. I did. [...] alternatives:
1. Default is big endian byte order. Little endian is explicit. 2. Default is native byte order. Little endian and big endian are explicit. 3. No default. Little endian and big endian are both explicit.
I implemented and committed the first alternative above (as a new attribute, 'bytes_le'), shortly before the freeze. -- ?!ng
participants (2)
-
Ka-Ping Yee -
Oren Tirosh