1 versions
1.1 nil uuid
1.2 version 1 (date-time , mac address)
1.3 version 2 (date-time , mac address, dce security version)
1.4 versions 3 , 5 (namespace name-based)
1.5 version 4 (random)
versions
for both variants 1 , 2, 5 versions defined in standards, , each version may more appropriate others in specific use cases. version indicated m in string representation.
version 1 uuids generated time , node id (usually mac address); version 2 uuids generated identifier (usually group or user id), time, , node id; versions 3 , 5 produce deterministic uuids generated hashing namespace identifier , name; , version 4 uuids generated using random or pseudo-random number.
nil uuid
the nil uuid, special case, uuid, 00000000-0000-0000-0000-000000000000; is, bits set zero.
version 1 (date-time , mac address)
version 1 concatenates 48-bit mac address of node (that is, computer generating uuid), 60-bit timestamp, being number of 100-nanosecond intervals since midnight 15 october 1582 coordinated universal time (utc), date on gregorian calendar first adopted. rfc 4122 states time value rolls on around 3400 ad, depending on algorithm used, implies 60-bit timestamp signed quantity. software, such libuuid library, treats timestamp unsigned, putting rollover time in 5236 ad.
a 13- or 14-bit uniquifying clock sequence extends timestamp in order handle cases processor clock not advance fast enough, or there multiple processors , uuid generators per node. each version 1 uuid corresponding single point in space (the node) , time (intervals , clock sequence), chance of 2 properly-generated version 1 uuid s being unintentionally same practically nil. since time , clock sequence total 74 bits, 2 (1.8x10 or 18 sextillion) version 1 uuids can generated per node id, @ maximum average rate of 163 billion per second per node id.
in contrast other uuid versions, version 1 , 2 uuids based on mac addresses network cards rely uniqueness in part on identifier issued central registration authority, namely organizationally unique identifier (oui) part of mac address, issued ieee manufacturers of networking equipment. uniqueness of version 1 , 2 uuids based on network card mac addresses depends on network card manufacturers assigning unique mac addresses cards, other manufacturing processes subject error.
usage of node s network card mac address node id means version 1 uuid can tracked computer created it. documents can traced computers created or edited through uuids embedded them word processing software. privacy hole used when locating creator of melissa virus.
rfc 4122 allow mac address in version 1 (or 2) uuid replaced random 48-bit node id, either because node not have mac address, or because not desirable expose it. in case, rfc requires least significant bit of first octet of node id should set 1. corresponds multicast bit in mac addresses , setting serves differentiate uuids node id randomly-generated based on mac addresses network cards, typically have unicast mac addresses.
version 2 (date-time , mac address, dce security version)
rfc 4122 reserves version 2 dce security uuids; not provide details. reason, many uuid implementations omit version 2. however, specification of version 2 uuids provided dce 1.1 authentication , security services specification.
version 2 uuids similar version 1, except least significant 8 bits of clock sequence replaced local domain number, , least significant 32 bits of timestamp replaced integer identifier meaningful within specified local domain. on posix systems, local domain numbers 0 , 1 user ids (uids), , group ids (gids), respectively, , other local domain numbers site-defined. on non-posix systems, local domain numbers site-defined.
the ability include 40-bit domain/identifier in uuid comes tradeoff. on 1 hand, 40 bits allow 1 trillion domain/identifier values per node id. on other hand, clock value truncated 28 significant bits, compared 60 bits in version 1, clock in version 2 uuid tick once every 429.49 seconds, little more 7 minutes, opposed every 100 nanoseconds version 1. , clock sequence of 6 bits, compared 14 bits in version 1, 64 unique uuid s per node/domain/identifier can generated per 7 minute clock tick, compared 16,384 clock sequence values version 1. thus, version 2 may not suitable cases uuids required, per node/domain/identifier, @ rate exceeding 1 per 7 seconds.
versions 3 , 5 (namespace name-based)
version 3 , 5 uuids generated hashing namespace identifier , name. version 3 uses md5 hashing algorithm, , version 5 uses sha1.
the namespace identifier uuid. specification provides uuids represent namespaces urls, qualified domain names, object identifiers, , x.500 distinguished names; desired uuid may used namespace designator.
to determine version 3 uuid corresponding given namespace , name, uuid of namespace transformed string of bytes, concatenated input name, hashed md5, yielding 128 bits. 6 or 7 bits replaced fixed values, 4-bit version (e.g. 0011 version 3), , 2- or 3-bit uuid variant (e.g. 10 indicating rfc 4122 uuids, or 110 indicating legacy microsoft guid). since 6 or 7 bits predetermined, 121 or 122 bits contribute uniqueness of uuid.
version 5 uuids similar, sha1 used instead of md5. since sha1 generates 160-bit digests, digest truncated 128-bits before version , variant bits inserted.
version 3 , 5 uuids have property same namespace , name map same uuid. however, neither namespace nor name can determined uuid, given other, except brute-force search.
rfc 4122 recommends version 5 (sha1) on version 3 (md5) , counsels against use of uuids of either version security credentials.
version 4 (random)
a version 4 uuid randomly generated. in other uuids, 4 bits used indicate version 4, , 2 or 3 bits indicate variant (10 or 110 variants 1 , 2, respectively). thus, variant 1 (that is, uuids) random version 4 uuid have 6 predetermined variant , version bits, leaving 122 bits randomly-generated part, total of 2, or 5.3x10 (5.3 undecillion) possible version 4 variant 1 uuids. there half many possible version 4 variant 2 uuids (legacy guids) because there 1 less random bit available, 3 bits being consumed variant.
some pseudorandom number generators lack necessary entropy produce sufficiently pseudorandom numbers. example, winapi guid generator, uses pseudorandom number generator, has been shown produce uuids follow predictable pattern. rfc 4122 advises distributed applications generating uuids @ variety of hosts must willing rely on random number source @ hosts. if not feasible, namespace variant should used.
Comments
Post a Comment