A UUID URN Namespace

1369 1371 A UUID URN Namespace 1373 1374 Microsoft 1375

1376 1377 1 Microsoft Way 1378 Redmond WA 98052 1379 US 1380 1381 +1 425-882-8080 1382 paulle@microsoft.com 1383

1384 1386 1387 VeriSign, Inc. 1388

1389 1390 21345 Ridgetop Circle 1391 Dulles VA 21345 1392 US 1393 1394 +1 770-717-0732 1395 michael@neonym.net 1396 http://www.verisignlabs.com 1397

1398 1400 1401 DataPower Technology, Inc. 1402

1403 1404 1 Alewife Center 1405 Cambridge MA 02142 1406 US 1407 1408 +1 617-864-0455 1409 rsalz@datapower.com 1410 http://www.datapower.com 1411

1412 1414 1415 URN, UUID 1416 1417 This specification defines a Uniform Resource Name namespace for 1418 UUIDs (Universally Unique IDentifier), also known as GUIDs (Globally 1419 Unique IDentifier). A UUID is 128 bits long, and can provide a 1420 guarantee of uniqueness across space and time. UUIDs were originally 1421 used in the Network Computing System (NCS) [1] and later in the Open 1422 Software Foundation's (OSF) Distributed Computing Environment 1423 . 1424 This specification is derived from the latter specification with the 1425 kind permission of the OSF (now known as The Open Group). Earlier 1426 versions of this document never left draft stage; this document 1427 incorporates that information here. 1428 1430 1432 1434

1435 This specification defines a Uniform Resource Name namespace for 1436 UUIDs (Universally Unique IDentifier), also known as GUIDs (Globally 1437 Unique IDentifier). A UUID is 128 bits long, and requires no central 1438 registration process. 1439 The information here is meant to be a concise guide for those wishing 1440 to implement services using UUIDs as URNs. Nothing in this document 1441 should be construed to mean that it overrides the DCE standards that 1442 defined UUIDs to begin with. 1443

1445

1446 One of the main reasons for using UUIDs is that no centralized 1447 authority is required to administer them (although one format uses 1448 IEEE 802.1 node identifiers, others do not). As a result, generation 1449 on demand can be completely automated, and they can be used for a wide 1450 variety of purposes. The UUID generation algorithm described here 1451 supports very high allocation rates: 10 million per second per machine 1452 if necessary, so that they could even be used as transaction IDs. 1453 UUIDs are of a fixed size (128 bits) which is reasonably small 1454 relative to other alternatives. This lends itself well to sorting, 1455 ordering, and hashing of all sorts, storing in databases, simple 1456 allocation, and ease of programming in general. 1457 Since UUIDs are unique and persistent, they make excellent Uniform 1458 Resource Names. The unique ability to generate a new UUID without a 1459 registration process allows for UUIDs to be one of the URNs with the 1460 lowest minting cost. 1461

1463

1464 1465 1466 UUID 1467 1468 Registration date: 2003-10-01 1469 1470 JTC 1/SC6 (ASN.1 Rapporteur Group) 1471 1472 A UUID is an identifier that is unique across both space and time, 1473 with respect to the space of all UUIDs. Since a UUID is a fixed 1474 size and contains a time field, it is possible for values to 1475 rollover (around A.D. 3400, depending on the specific algorithm 1476 used). A UUID can be used for multiple purposes, from tagging 1477 objects with an extremely short lifetime, to reliably identifying 1478 very persistent objects across a network. 1479 1480 The internal representation of a UUID is a specific sequence of 1481 bits in memory, as described in . 1482 In order to accurately represent a UUID as a URN, it is necessary 1483 to convert the bit sequence to a string representation. 1484 1485 Each field is treated as an integer and has its value printed as a 1486 zero-filled hexadecimal digit string with the most significant 1487 digit first. The hexadecimal values a through f are 1488 output as lower case characters, and are case insensitive on 1489 input. 1490 1491 The formal definition of the UUID string representation is 1492 provided by the following ABNF :

1510 1511 The following is an example of the string representation of a UUID 1512 as a URN:

1515 1516 1517 1518 1519 1520 This document specifies three algorithms to generate UUIDs: the 1521 first leverages the unique values of 802.1 MAC addresses to 1522 guarantee uniqueness, the second another uses pseudo-random number 1523 generators, and the third uses cryptographic hashing and 1524 application-provided text strings. As a result, it is possible to 1525 guarantee that UUIDs generated according to the mechanisms here 1526 will be unique from all other UUIDs that have been or will be 1527 assigned. 1528 1529 UUIDs are inherently very difficult to resolve in a global sense. 1530 This, coupled with the fact that UUIDs are temporally unique 1531 within their spatial context, ensures that UUIDs will remain as 1532 persistent as possible. 1533 1534 Generating a UUID does not require that it be a registration 1535 authority be contacted. One algorithm requires a unique value over 1536 space for each generator. This value is typically an IEEE 802 MAC 1537 address, usually already available on network-connected hosts. The 1538 address can be assigned from an address block obtained from the 1539 IEEE registration authority. If no such address is available, or 1540 privacy concerns make its use undesirable, 1541 specifies two 1542 alternatives; another approach is to use version 3 or version 4 1543 UUIDs as defined below. 1544 1545 Since UUIDs are not globally resolvable, this is not 1546 applicable. 1547 1548 Consider each field of the UUID to be an unsigned integer as 1549 shown in the table in section . Then, 1550 to compare a pair of UUIDs, arithmetically compare the 1551 corresponding fields from each UUID in order of significance and 1552 according to their data type. Two UUIDs are equal if and only if 1553 all the corresponding fields are equal. 1554 1555 As an implementation note, on many systems equality comparison can 1556 be performed by doing the appropriate byte-order 1557 canonicalization, and then treating the two UUIDs as 128-bit 1558 unsigned integers. 1559 1560 UUIDs as defined in this document can also be ordered 1561 lexicographically. For a pair of UUIDs, the first one follows the 1562 second if the most significant field in which the UUIDs differ is 1563 greater for the first UUID. The second precedes the first if the 1564 most significant field in which the UUIDs differ is greater for 1565 the second UUID. 1566 1567 The string representation of a UUID is fully compatible with the 1568 URN syntax. When converting from an bit-oriented, in-memory 1569 representation of a UUID into a URN, care must be taken to 1570 strictly adhere to the byte order issues mentioned in the string 1571 representation section. 1572 1573 Apart from determining if the timestamp portion of the UUID is in 1574 the future and therefore not yet assignable, there is no mechanism 1575 for determining if a UUID is 'valid' in any real sense. 1576 1577 UUIDs are global in scope. 1578 1579 1580

1582

1584

1585 In its most general form, all that can be said of the UUID format is 1586 that a UUID is 16 octets, and that some bits of the eight octet -- 1587 the variant field specified below -- determine finer 1588 structure. 1590

1591 The variant field determines the layout of the UUID. That is, the 1592 interpretation of all other bits in the UUID depends on the 1593 setting of the bits in the variant field. As such, it could more 1594 accurately be called a type field; we retain the original term for 1595 compatibility. The variant field consists of a variable number of 1596 the most significant bits of the eighth octet of the UUID. 1597 The following table lists the contents of the variant field, 1598 where the letter "x" indicates a "don't-care" value. 1599

1611 1612 Interoperability (in any form) with variants other than the one 1613 defined here is not guaranteed. This is unlikely to be an issue 1614 in practice. 1615

1617

1618 To minimize confusion about bit assignments within octets, the 1619 UUID record definition is defined only in terms of fields that 1620 are integral numbers of octets. The fields are presented with the 1621 most significant one first.

1646 1648 In the absence of explicit application or presentation protocol 1649 specification to the contrary, a UUID is encoded as a 128-bit 1650 object, as follows: the fields are encoded as 16 octets, with the 1651 sizes and order of the fields defined above, and with each field 1652 encoded with the Most Significant Byte first (this is known as 1653 network byte order). Note that the field names, particularly 1654 for multiplexed fields, follow historical 1655 practice.

1668 1669

1671

1672 The version number is in the most significant four bits of the 1673 time stamp (bits four through seven of the time_hi_and_version 1674 field). 1675 The following table lists the currently-defined versions for 1676 this UUID variant.

1692 The version is more accurately a sub-type; again, we retain the 1693 term for compatibility. 1694

1696

1697 The timestamp is a 60-bit value. For UUID version 1, this is 1698 represented by Coordinated Universal Time (UTC) as a count of 1699 100-nanosecond intervals since 00:00:00.00, 15 October 1582 (the 1700 date of Gregorian reform to the Christian calendar). 1701 For systems that do not have UTC available, but do have the 1702 local time, they may use that instead of UTC, as long as they do 1703 so consistently throughout the system. This is not recommended 1704 however, particularly since all that is needed to generate UTC 1705 from local time is a time zone offset. 1706 For UUID version 3, the timestamp is a 60-bit value constructed 1707 from a name as described in . 1708 For UUID version 4, it is a randomly or pseudo-randomly 1709 generated 60-bit value, as described in 1710 . 1711

1713

1714 For UUID version 1, the clock sequence is used to help avoid 1715 duplicates that could arise when the clock is set backwards in 1716 time or if the node ID changes. 1717 If the clock is set backwards, or even might have been set 1718 backwards (e.g., while the system was powered off), and the UUID 1719 generator can not be sure that no UUIDs were generated with 1720 timestamps larger than the value to which the clock was set, 1721 then the clock sequence has to be changed. If the previous value 1722 of the clock sequence is known, it can be just incremented; 1723 otherwise it should be set to a random or high-quality pseudo 1724 random value. 1725 Similarly, if the node ID changes (e.g. because a network card 1726 has been moved between machines), setting the clock sequence to 1727 a random number minimizes the probability of a duplicate due to 1728 slight differences in the clock settings of the machines. (If 1729 the value of clock sequence associated with the changed node ID 1730 were known, then the clock sequence could just be incremented, 1731 but that is unlikely.) 1732 The clock sequence MUST be originally (i.e., once in the 1733 lifetime of a system) initialized to a random number to minimize 1734 the correlation across systems. This provides maximum protection 1735 against node identifiers that may move or switch from system to 1736 system rapidly. The initial value MUST NOT be correlated to the 1737 node identifier. 1738 For UUID version 3, it is a 14-bit value constructed from a 1739 name as described in . 1740 For UUID version 4, it is a randomly or pseudo-randomly 1741 generated 14-bit value as described in 1742 . 1743

1745

1746 For UUID version 1, the node field consists of an IEEE 802 1747 MAC address, usually the host address. For systems with multiple 1748 IEEE 802 addresses, any available one can be used. The lowest 1749 addressed octet (octet number 10) contains the global/local bit 1750 and the unicast/multicast bit, and is the first octet of the 1751 address transmitted on an 802.3 LAN. 1752 For systems with no IEEE address, a randomly or pseudo-randomly 1753 generated value may be used; see . 1754 The multicast bit must be set in such addresses, in order that 1755 they will never conflict with addresses obtained from network 1756 cards. 1757 For UUID version 3, the node field is a 48-bit value constructed 1758 from a name as described in . 1759 For UUID version 4, the node field is a randomly or 1760 pseudo-randomly generated 48-bit value as described in 1761 . 1762

1764

1765 The nil UUID is special form of UUID that is specified to have 1766 all 128 bits set to zero. 1767

1769

1771

1772 Various aspects of the algorithm for creating a version 1 UUID are 1773 discussed in the following sections. 1775

1776 The following algorithm is simple, correct, and inefficient: 1777 1778 Obtain a system-wide global lock 1779 From a system-wide shared stable store (e.g., a file), read 1780 the UUID generator state: the values of the time stamp, clock 1781 sequence, and node ID used to generate the last UUID. 1782 Get the current time as a 60-bit count of 100-nanosecond 1783 intervals since 00:00:00.00, 15 October 1582 1784 Get the current node ID 1785 If the state was unavailable (e.g., non-existent or 1786 corrupted), or the saved node ID is different than the current 1787 node ID, generate a random clock sequence value 1788 If the state was available, but the saved time stamp is later 1789 than the current time stamp, increment the clock sequence 1790 value 1791 Save the state (current time stamp, clock sequence, and node 1792 ID) back to the stable store 1793 Release the global lock 1794 Format a UUID from the current time stamp, clock sequence, 1795 and node ID values according to the steps in 1796 . 1797 1798 1799 If UUIDs do not need to be frequently generated, the above 1800 algorithm may be perfectly adequate. For higher performance 1801 requirements, however, issues with the basic algorithm include: 1802 1803 Reading the state from stable storage each time is 1804 inefficient 1805 The resolution of the system clock may not be 1806 100-nanoseconds 1807 Writing the state to stable storage each time is 1808 inefficient 1809 Sharing the state across process boundaries may be 1810 inefficient 1811 1812 1813 Each of these issues can be addressed in a modular fashion by 1814 local improvements in the functions that read and write the state 1815 and read the clock. We address each of them in turn in the 1816 following sections. 1817

1818 The state only needs to be read from stable storage once at boot 1819 time, if it is read into a system-wide shared volatile store (and 1820 updated whenever the stable store is updated). 1821 If an implementation does not have any stable store available, 1822 then it can always say that the values were unavailable. This is 1823 the least desirable implementation, because it will increase the 1824 frequency of creation of new clock sequence numbers, which 1825 increases the probability of duplicates. 1826 If the node ID can never change (e.g., the net card is inseparable 1827 from the system), or if any change also reinitializes the clock 1828 sequence to a random value, then instead of keeping it in stable 1829 store, the current node ID may be returned. 1830

1831

1832 The time stamp is generated from the system time, whose resolution 1833 may be less than the resolution of the UUID time stamp. 1834 If UUIDs do not need to be frequently generated, the time stamp 1835 can simply be the system time multiplied by the number of 1836 100-nanosecond intervals per system time interval. 1837 If a system overruns the generator by requesting too many UUIDs 1838 within a single system time interval, the UUID service MUST either: 1839 return an error, or stall the UUID generator until the system clock 1840 catches up. 1841 A high resolution time stamp can be simulated by keeping a count 1842 of how many UUIDs have been generated with the same value of the 1843 system time, and using it to construction the low-order bits of the 1844 time stamp. The count will range between zero and the number of 1845 100-nanosecond intervals per system time interval. 1846 Note: if the processors overrun the UUID generation frequently, 1847 additional node identifiers can be allocated to the system, which 1848 will permit higher speed allocation by making multiple UUIDs 1849 potentially available for each time stamp value. 1850

1851

1852 The state does not always need to be written to stable store 1853 every time a UUID is generated. The timestamp in the stable store 1854 can be periodically set to a value larger than any yet used in a 1855 UUID; as long as the generated UUIDs have time stamps less than 1856 that value, and the clock sequence and node ID remain unchanged, 1857 only the shared volatile copy of the state needs to be updated. 1858 Furthermore, if the time stamp value in stable store is in the 1859 future by less than the typical time it takes the system to 1860 reboot, a crash will not cause a reinitialization of the clock 1861 sequence. 1862

1863

1864 If it is too expensive to access shared state each time a UUID is 1865 generated, then the system-wide generator can be implemented to 1866 allocate a block of time stamps each time it is called, and a 1867 per-process generator can allocate from that block until it is 1868 exhausted. 1869

1870

1871

1872 Version 1 UUIDs are generated according to the following 1873 algorithm: 1874 1875 Determine the values for the UTC-based timestamp and clock 1876 sequence to be used in the UUID, as described in 1877 . 1878 For the purposes of this algorithm, consider the timestamp 1879 to be a 60-bit unsigned integer and the clock sequence to be 1880 a 14-bit unsigned integer. Sequentially number the bits in a 1881 field, starting with zero for the least significant bit. 1882 Set the time_low field equal to the least significant 32 1883 bits (bits zero through 31) of the time stamp in the same 1884 order of significance. 1885 Set the time_mid field equal to bits 32 through 47 from the 1886 time stamp in the same order of significance. 1887 Set the 12 least significant bits (bits zero through 11) of 1888 the time_hi_and_version field equal to bits 48 through 59 1889 from the time stamp in the same order of significance. 1890 Set the four most significant bits (bits 12 through 15) of 1891 the time_hi_and_version field to the four-bit version number 1892 corresponding to the UUID version being created, as shown in 1893 the table above. 1894 Set the clock_seq_low field to the eight least significant 1895 bits (bits zero through seven) of the clock sequence in the 1896 same order of significance. 1897 Set the six least significant bits (bits zero through five) 1898 of the clock_seq_hi_and_reserved field to the six most 1899 significant bits (bits eight through 13) of the clock 1900 sequence in the same order of significance. 1901 Set the two most significant bits (bits six and seven) of 1902 the clock_seq_hi_and_reserved to zero and one, 1903 respectively. 1904 Set the node field to the 48-bit IEEE address in the same 1905 order of significance as the address. 1906 1907 1908

1910

1912

1913 The version 3 UUID is meant for generating UUIDs from "names" that 1914 are drawn from, and unique within, some "name space." The concept 1915 of name and name space should be broadly construed, and not limited 1916 to textual names. For example, some name spaces are the domain 1917 name system, URLs, ISO Object IDs (OIDs), X.500 Distinguished Names 1918 (DNs), and reserved words in a programming language. The mechanisms 1919 or conventions for allocating names from, and ensuring their 1920 uniqueness within, their name spaces are beyond the scope of this 1921 specification. 1922 The requirements for version 3 UUIDs are as follows: 1923 1924 The UUIDs generated at different times from the same name in 1925 the same namespace MUST be equal 1926 The UUIDs generated from two different names in the same 1927 namespace should be different (with very high probability) 1928 The UUIDs generated from the same name in two different 1929 namespaces should be different with (very high probability) 1930 If two UUIDs that were generated from names are equal, then 1931 they were generated from the same name in the same namespace 1932 (with very high probability). 1933 1934 1935 The algorithm for generating the a UUID from a name and a name 1936 space are as follows: 1937 1938 Allocate a UUID to use as a "name space ID" for all UUIDs 1939 generated from names in that name space; see 1940 for some pre-defined values 1941 Convert the name to a canonical sequence of octets (as defined 1942 by the standards or conventions of its name space); put the name 1943 space ID in network byte order 1944 Compute the MD5 hash of the name 1945 space ID concatenated with the name 1946 Set octets zero through three of the time_low field to octets 1947 zero through three of the MD5 hash 1948 Set octets zero and one of the time_mid field to octets four 1949 and five of the MD5 hash 1950 Set octets zero and one of the time_hi_and_version field to 1951 octets six and seven of the MD5 hash 1952 Set the four most significant bits (bits 12 through 15) of the 1953 time_hi_and_version field to the four-bit version number from 1954 . 1955 Set the clock_seq_hi_and_reserved field to octet eight of the MD5 1956 hash 1957 Set the two most significant bits (bits six and seven) of the 1958 clock_seq_hi_and_reserved to zero and one, respectively. 1959 Set the clock_seq_low field to octet nine of the MD5 hash 1960 Set octets zero through five of the node field to octets then 1961 through fifteen of the MD5 hash 1962 Convert the resulting UUID to local byte order. 1963 1964 1965

1967

1968 The version 4 UUID is meant for generating UUIDs from truly-random or 1969 pseudo-random numbers. 1970 The algorithm is as follows: 1971 1972 Set the two most significant bits (bits six and seven) of the 1973 clock_seq_hi_and_reserved to zero and one, respectively. 1974 Set the four most significant bits (bits 12 through 15) of the 1975 time_hi_and_version field to the four-bit version number from 1976 . 1977 Set all the other bits to randomly (or pseudo-randomly) chosen 1978 values. 1979 1980 1981 See for a discussion 1982 on random numbers. 1983

1985

1986 This section describes how to generate a version 1 UUID if an IEEE 1987 802 address is not available, or its use is not desired. 1988 One approach is to contact the IEEE and get a separate block of 1989 addresses. At the time of writing, the application could 1990 be found at 1991 , 1992 and the cost was US$550. 1993 A better solution is to obtain a 47-bit cryptographic quality 1994 random number, and use it as the low 47 bits of the node ID, with the 1995 least significant bit of the first octet of the node ID set to one. 1996 This bit is the unicast/multicast bit, which will never be set in 1997 IEEE 802 addresses obtained from network cards; hence, there can 1998 never be a conflict between UUIDs generated by machines with and 1999 without network cards. (Recall that the IEEE 802 spec talks 2000 about transmission order, which is the opposite of the in-memory 2001 representation that is discussed in this document.) 2002 If a system does not have the capability to generate cryptographic 2003 quality random numbers, then implementation advice can be found in 2004 RFC1750. 2005 2006 In addition, items such as the computer's name and the name of the 2007 operating system, while not strictly speaking random, will help 2008 differentiate the results from those obtained by other systems. 2009 The exact algorithm to generate a node ID using these data is system 2010 specific, because both the data available and the functions to obtain 2011 them are often very system specific. A generic approach, however is 2012 to accumulate as many sources as possible into a buffer, and use 2013 a message digest such as MD5 or 2014 SHA-1, take an arbitrary six 2015 bytes from the hash value, and set the multicast bit as described 2016 above. 2017

2018

2020

2021 The use of UUIDs is extremely pervasive in computing. They comprise 2022 the core identifier infrastructure for many operating systems 2023 (Microsoft Windows) and applications (the Mozilla browser) and in many 2024 cases, become exposed to the web in many non-standard ways. This 2025 specification attempts to standardize that practice as openly as 2026 possible and in a way that attempts to benefit the entire 2027 Internet. 2028

2030

2031 Do not assume that UUIDs are hard to guess; they should not be used 2032 as security capabilities (identifiers whose mere possession grants 2033 access), for example. 2034 Do not assume that it is easy to determine if a UUID has been 2035 slightly transposed in order to redirect a reference to another 2036 object. Humans do not have the ability to easily check the integrity 2037 of a UUID by simply glancing at it. 2038

2040

2041 This document draws heavily on the OSF DCE specification for UUIDs. 2042 Ted Ts'o provided helpful comments, especially on the byte ordering 2043 section which we mostly plagiarized from a proposed wording he 2044 supplied (all errors in that section are our responsibility, 2045 however). 2046 We are also grateful to the careful reading and bit-twiddling of 2047 Ralph S. Engelschall, John Larmouth, and Paul Thorpe. 2048

2050 2052 2054 2055 2056 2057 Network Computing Architecture 2058 2059 2060 2061 2062 2063 2064 2065 2066 2067 2068 2069 2070 2072 2073 2074 DCE: Remote Procedure Call 2075 2076 2077 2078 2079 2080 2081 2082 2084 2085 2086 2087 2088 2089 2091

2093 This implementation consists of 5 files: uuid.h, uuid.c, sysdep.h, 2094 sysdep.c and utest.c. The uuid.* files are the system independent 2095 implementation of the UUID generation algorithms described above, with 2096 all the optimizations described above except efficient state sharing 2097 across processes included. The code has been tested on Linux (Red Hat 2098 4.0) with GCC (2.7.2), and Windows NT 4.0 with VC++ 5.0. The code 2099 assumes 64-bit integer support, which makes it a lot clearer. 2100 All the following source files should be considered to have the 2101 following copyright notice included:

2160 #include 2161 #include 2162 #include 2163 #include "sysdep.h" 2164 #include "uuid.h" 2166 /* various forward declarations */ 2167 static int read_state(unsigned16 *clockseq, uuid_time_t *timestamp, 2168 uuid_node_t *node); 2169 static void write_state(unsigned16 clockseq, uuid_time_t timestamp, 2170 uuid_node_t node); 2171 static void format_uuid_v1(uuid_t *uuid, unsigned16 clockseq, 2172 uuid_time_t timestamp, uuid_node_t node); 2173 static void format_uuid_v3(uuid_t *uuid, unsigned char hash[16]); 2174 static void get_current_time(uuid_time_t *timestamp); 2175 static unsigned16 true_random(void); 2177 /* uuid_create -- generator a UUID */ 2178 int uuid_create(uuid_t *uuid) 2179 { 2180 uuid_time_t timestamp, last_time; 2181 unsigned16 clockseq; 2182 uuid_node_t node; 2183 uuid_node_t last_node; 2184 int f; 2186 /* acquire system-wide lock so we're alone */ 2187 LOCK; 2189 /* get time, node ID, saved state from non-volatile storage */ 2190 get_current_time(×tamp); 2191 get_ieee_node_identifier(&node); 2192 f = read_state(&clockseq, &last_time, &last_node); 2194 /* if no NV state, or if clock went backwards, or node ID changed 2195 (e.g., new network card) change clockseq */ 2196 if (!f || memcmp(&node, &last_node, sizeof node)) 2197 clockseq = true_random(); 2198 else if (timestamp < last_time) 2199 clockseq++; 2201 /* save the state for next time */ 2202 write_state(clockseq, timestamp, node); 2204 UNLOCK; 2206 /* stuff fields into the UUID */ 2207 format_uuid_v1(uuid, clockseq, timestamp, node); 2208 return 1; 2209 } 2211 /* format_uuid_v1 -- make a UUID from the timestamp, clockseq, 2212 and node ID */ 2213 void format_uuid_v1(uuid_t* uuid, unsigned16 clock_seq, 2214 uuid_time_t timestamp, uuid_node_t node) 2215 { 2216 /* Construct a version 1 uuid with the information we've gathered 2217 plus a few constants. */ 2218 uuid->time_low = (unsigned long)(timestamp & 0xFFFFFFFF); 2219 uuid->time_mid = (unsigned short)((timestamp >> 32) & 0xFFFF); 2220 uuid->time_hi_and_version = 2221 (unsigned short)((timestamp >> 48) & 0x0FFF); 2222 uuid->time_hi_and_version |= (1 << 12); 2223 uuid->clock_seq_low = clock_seq & 0xFF; 2224 uuid->clock_seq_hi_and_reserved = (clock_seq & 0x3F00) >> 8; 2225 uuid->clock_seq_hi_and_reserved |= 0x80; 2226 memcpy(&uuid->node, &node, sizeof uuid->node); 2227 } 2229 /* data type for UUID generator persistent state */ 2230 typedef struct { 2231 uuid_time_t ts; /* saved timestamp */ 2232 uuid_node_t node; /* saved node ID */ 2233 unsigned16 cs; /* saved clock sequence */ 2234 } uuid_state; 2236 static uuid_state st; 2238 /* read_state -- read UUID generator state from non-volatile store */ 2239 int read_state(unsigned16 *clockseq, uuid_time_t *timestamp, 2240 uuid_node_t *node) 2241 { 2242 static int inited = 0; 2243 FILE *fp; 2245 /* only need to read state once per boot */ 2246 if (!inited) { 2247 fp = fopen("state", "rb"); 2248 if (fp == NULL) 2249 return 0; 2250 fread(&st, sizeof st, 1, fp); 2251 fclose(fp); 2252 inited = 1; 2253 } 2254 *clockseq = st.cs; 2255 *timestamp = st.ts; 2256 *node = st.node; 2257 return 1; 2258 } 2260 /* write_state -- save UUID generator state back to non-volatile storage */ 2261 void write_state(unsigned16 clockseq, uuid_time_t timestamp, 2262 uuid_node_t node) 2263 { 2264 static int inited = 0; 2265 static uuid_time_t next_save; 2266 FILE* fp; 2268 if (!inited) { 2269 next_save = timestamp; 2270 inited = 1; 2271 } 2273 /* always save state to volatile shared state */ 2274 st.cs = clockseq; 2275 st.ts = timestamp; 2276 st.node = node; 2277 if (timestamp >= next_save) { 2278 fp = fopen("state", "wb"); 2279 fwrite(&st, sizeof st, 1, fp); 2280 fclose(fp); 2281 /* schedule next save for 10 seconds from now */ 2282 next_save = timestamp + (10 * 10 * 1000 * 1000); 2283 } 2284 } 2286 /* get-current_time -- get time as 60-bit 100ns ticks since UUID epoch. 2287 Compensate for the fact that real clock resolution is 2288 less than 100ns. */ 2289 void get_current_time(uuid_time_t *timestamp) 2290 { 2291 static int inited = 0; 2292 static uuid_time_t time_last; 2293 static unsigned16 uuids_this_tick; 2294 uuid_time_t time_now; 2296 if (!inited) { 2297 get_system_time(&time_now); 2298 uuids_this_tick = UUIDS_PER_TICK; 2299 inited = 1; 2300 } 2302 for ( ; ; ) { 2303 get_system_time(&time_now); 2305 /* if clock reading changed since last UUID generated, */ 2306 if (time_last != time_now) { 2307 /* reset count of uuids gen'd with this clock reading */ 2308 uuids_this_tick = 0; 2309 time_last = time_now; 2310 break; 2311 } 2312 if (uuids_this_tick < UUIDS_PER_TICK) { 2313 uuids_this_tick++; 2314 break; 2315 } 2316 /* going too fast for our clock; spin */ 2317 } 2318 /* add the count of uuids to low order bits of the clock reading */ 2319 *timestamp = time_now + uuids_this_tick; 2320 } 2322 /* true_random -- generate a crypto-quality random number. 2323 **This sample doesn't do that.** */ 2324 static unsigned16 true_random(void) 2325 { 2326 static int inited = 0; 2327 uuid_time_t time_now; 2329 if (!inited) { 2330 get_system_time(&time_now); 2331 time_now = time_now / UUIDS_PER_TICK; 2332 srand((unsigned int)(((time_now >> 32) ^ time_now) & 0xffffffff)); 2333 inited = 1; 2334 } 2336 return rand(); 2337 } 2339 /* uuid_create_from_name -- create a UUID using a "name" from a "name 2340 space" */ 2341 void uuid_create_from_name(uuid_t *uuid, uuid_t nsid, void *name, 2342 int namelen) 2343 { 2344 MD5_CTX c; 2345 unsigned char hash[16]; 2346 uuid_t net_nsid; 2348 /* put name space ID in network byte order so it hashes the same 2349 no matter what endian machine we're on */ 2350 net_nsid = nsid; 2351 htonl(net_nsid.time_low); 2352 htons(net_nsid.time_mid); 2353 htons(net_nsid.time_hi_and_version); 2355 MD5Init(&c); 2356 MD5Update(&c, &net_nsid, sizeof net_nsid); 2357 MD5Update(&c, name, namelen); 2358 MD5Final(hash, &c); 2360 /* the hash is in network byte order at this point */ 2361 format_uuid_v3(uuid, hash); 2362 } 2364 /* format_uuid_v3 -- make a UUID from a (pseudo)random 128-bit number */ 2365 void format_uuid_v3(uuid_t *uuid, unsigned char hash[16]) 2366 { 2367 /* convert UUID to local byte order */ 2368 memcpy(uuid, hash, sizeof *uuid); 2369 ntohl(uuid->time_low); 2370 ntohs(uuid->time_mid); 2371 ntohs(uuid->time_hi_and_version); 2373 /* put in the variant and version bits */ 2374 uuid->time_hi_and_version &= 0x0FFF; 2375 uuid->time_hi_and_version |= (3 << 12); 2376 uuid->clock_seq_hi_and_reserved &= 0x3F; 2377 uuid->clock_seq_hi_and_reserved |= 0x80; 2378 } 2380 /* uuid_compare -- Compare two UUID's "lexically" and return */ 2381 #define CHECK(f1, f2) if (f1 != f2) return f1 < f2 ? -1 : 1; 2382 int uuid_compare(uuid_t *u1, uuid_t *u2) 2383 { 2384 int i; 2386 CHECK(u1->time_low, u2->time_low); 2387 CHECK(u1->time_mid, u2->time_mid); 2388 CHECK(u1->time_hi_and_version, u2->time_hi_and_version); 2389 CHECK(u1->clock_seq_hi_and_reserved, u2->clock_seq_hi_and_reserved); 2390 CHECK(u1->clock_seq_low, u2->clock_seq_low) 2391 for (i = 0; i < 6; i++) { 2392 if (u1->node[i] < u2->node[i]) 2393 return -1; 2394 if (u1->node[i] > u2->node[i]) 2395 return 1; 2396 } 2397 return 0; 2398 } 2399 #undef CHECK 2401 sysdep.h 2403 #include "copyrt.h" 2404 /* remove the following define if you aren't running WIN32 */ 2405 #define WININC 0 2407 #ifdef WININC 2408 #include 2409 #else 2410 #include 2411 #include 2412 #include 2413 #endif 2415 #include "global.h" 2416 /* change to point to where MD5 .h's live; RFC 1321 has sample 2417 implementation */ 2418 #include "md5.h" 2420 /* set the following to the number of 100ns ticks of the actual 2421 resolution of your system's clock */ 2422 #define UUIDS_PER_TICK 1024 2424 /* Set the following to a calls to get and release a global lock */ 2425 #define LOCK 2426 #define UNLOCK 2428 typedef unsigned long unsigned32; 2429 typedef unsigned short unsigned16; 2430 typedef unsigned char unsigned8; 2431 typedef unsigned char byte; 2433 /* Set this to what your compiler uses for 64-bit data type */ 2434 #ifdef WININC 2435 #define unsigned64_t unsigned __int64 2436 #define I64(C) C 2437 #else 2438 #define unsigned64_t unsigned long long 2439 #define I64(C) C##LL 2440 #endif 2442 typedef unsigned64_t uuid_time_t; 2443 typedef struct { 2444 char nodeID[6]; 2445 } uuid_node_t; 2447 void get_ieee_node_identifier(uuid_node_t *node); 2448 void get_system_time(uuid_time_t *uuid_time); 2449 void get_random_info(char seed[16]); 2451 sysdep.c 2453 #include "copyrt.h" 2454 #include 2455 #include "sysdep.h" 2457 /* system dependent call to get IEEE node ID. 2458 This sample implementation generates a random node ID. */ 2459 void get_ieee_node_identifier(uuid_node_t *node) 2460 { 2461 static inited = 0; 2462 static uuid_node_t saved_node; 2463 char seed[16]; 2464 FILE *fp; 2466 if (!inited) { 2467 fp = fopen("nodeid", "rb"); 2468 if (fp) { 2469 fread(&saved_node, sizeof saved_node, 1, fp); 2470 fclose(fp); 2471 } 2472 else { 2473 get_random_info(seed); 2474 seed[0] |= 0x01; 2475 memcpy(&saved_node, seed, sizeof saved_node); 2476 fp = fopen("nodeid", "wb"); 2477 if (fp) { 2478 fwrite(&saved_node, sizeof saved_node, 1, fp); 2479 fclose(fp); 2480 } 2481 } 2482 inited = 1; 2483 } 2485 *node = saved_node; 2486 } 2488 /* system dependent call to get the current system time. Returned as 2489 100ns ticks since UUID epoch, but resolution may be less than 100ns. */ 2490 #ifdef _WINDOWS_ 2492 void get_system_time(uuid_time_t *uuid_time) 2493 { 2494 ULARGE_INTEGER time; 2496 /* NT keeps time in FILETIME format which is 100ns ticks since 2497 Jan 1, 1601. UUIDs use time in 100ns ticks since Oct 15, 1582. 2498 The difference is 17 Days in Oct + 30 (Nov) + 31 (Dec) 2499 + 18 years and 5 leap days. */ 2500 GetSystemTimeAsFileTime((FILETIME *)&time); 2501 time.QuadPart += 2502 (unsigned __int64) (1000*1000*10) // seconds 2503 * (unsigned __int64) (60 * 60 * 24) // days 2504 * (unsigned __int64) (17+30+31+365*18+5); // # of days 2505 *uuid_time = time.QuadPart; 2506 } 2508 /* Sample code, not for use in production; see RFC 1750 */ 2509 void get_random_info(char seed[16]) 2510 { 2511 MD5_CTX c; 2512 struct { 2513 MEMORYSTATUS m; 2514 SYSTEM_INFO s; 2515 FILETIME t; 2516 LARGE_INTEGER pc; 2517 DWORD tc; 2518 DWORD l; 2519 char hostname[MAX_COMPUTERNAME_LENGTH + 1]; 2520 } r; 2522 MD5Init(&c); 2523 GlobalMemoryStatus(&r.m); 2524 GetSystemInfo(&r.s); 2525 GetSystemTimeAsFileTime(&r.t); 2526 QueryPerformanceCounter(&r.pc); 2527 r.tc = GetTickCount(); 2528 r.l = MAX_COMPUTERNAME_LENGTH + 1; 2529 GetComputerName(r.hostname, &r.l); 2530 MD5Update(&c, &r, sizeof r); 2531 MD5Final(seed, &c); 2532 } 2534 #else 2536 void get_system_time(uuid_time_t *uuid_time) 2537 { 2538 struct timeval tp; 2540 gettimeofday(&tp, (struct timezone *)0); 2542 /* Offset between UUID formatted times and Unix formatted times. 2543 UUID UTC base time is October 15, 1582. 2544 Unix base time is January 1, 1970.*/ 2545 *uuid_time = ((unsigned64)tp.tv_sec * 10000000) 2546 + ((unsigned64)tp.tv_usec * 10) 2547 + I64(0x01B21DD213814000); 2548 } 2550 /* Sample code, not for use in production; see RFC 1750 */ 2551 void get_random_info(char seed[16]) 2552 { 2553 MD5_CTX c; 2554 struct { 2555 struct sysinfo s; 2556 struct timeval t; 2557 char hostname[257]; 2558 } r; 2560 MD5Init(&c); 2561 sysinfo(&r.s); 2562 gettimeofday(&r.t, (struct timezone *)0); 2563 gethostname(r.hostname, 256); 2564 MD5Update(&c, &r, sizeof r); 2565 MD5Final(seed, &c); 2566 } 2568 #endif 2570 utest.c 2572 #include "copyrt.h" 2573 #include "sysdep.h" 2574 #include 2575 #include "uuid.h" 2577 uuid_t NameSpace_DNS = { /* 6ba7b810-9dad-11d1-80b4-00c04fd430c8 */ 2578 0x6ba7b810, 2579 0x9dad, 2580 0x11d1, 2581 0x80, 0xb4, 0x00, 0xc0, 0x4f, 0xd4, 0x30, 0xc8 2582 }; 2584 /* puid -- print a UUID */ 2585 void puid(uuid_t u) 2586 { 2587 int i; 2589 printf("%8.8x-%4.4x-%4.4x-%2.2x%2.2x-", u.time_low, u.time_mid, 2590 u.time_hi_and_version, u.clock_seq_hi_and_reserved, 2591 u.clock_seq_low); 2592 for (i = 0; i < 6; i++) 2593 printf("%2.2x", u.node[i]); 2594 printf("\n"); 2595 } 2597 /* Simple driver for UUID generator */ 2598 void main(int argc, char **argv) 2599 { 2600 uuid_t u; 2601 int f; 2603 uuid_create(&u); 2604 printf("uuid_create(): "); puid(u); 2606 f = uuid_compare(&u, &u); 2607 printf("uuid_compare(u,u): %d\n", f); /* should be 0 */ 2608 f = uuid_compare(&u, &NameSpace_DNS); 2609 printf("uuid_compare(u, NameSpace_DNS): %d\n", f); /* s.b. 1 */ 2610 f = uuid_compare(&NameSpace_DNS, &u); 2611 printf("uuid_compare(NameSpace_DNS, u): %d\n", f); /* s.b. -1 */ 2612 uuid_create_from_name(&u, NameSpace_DNS, "www.widgets.com", 15); 2613 printf("uuid_create_from_name(): "); puid(u); 2614 } 2615 ]]> 2616 2617

2619

2620

2627 2628

2630

2631 This appendix lists the name space IDs for some potentially 2632 interesting name spaces, as initialized C structures and in the string 2633 representation defined above. 2634

2667 2668

2670 2672