DrUUID RFC 4122 library manual

UUID UUID::mint( [int version [, ... ]] )

The UUID::mint() method generates ("mints", like coinage) a new UUID. It is capable of producing Version 1 (time-based), Version 3 (MD5 hash-based), Version 4 (random) and Version 5 (SHA-1 hash-based) UUIDs. Its argument list is generic: required and optional argument depend upon the specified version to produce.

Version 1

UUID UUID::mint( void )
UUID UUID::mint( 1 [, string node [, string sequence [, string time ]]] )

Version 1 UUIDs (the default type) are generated based on the current time and a MAC address (called a node).

If specified, node should be either a 6-byte binary string or a 12-character hexadecimal string (with or without separators) representing a MAC address. DrUUID does not attempt to detect the host's MAC address. Invalid nodes will throw an exception.

The sequence argument specifies a clock sequence and should be a two-byte binary string. This should only be used for debugging. Invalid sequences will throw an exception.

Finally, the time argument may be specified to employ a past or future time (as a Unix timestamp with microseconds like that returned by microtime() for example) instead of the curent time. This should only be used for debugging and never used to generate UUIDs for any purpose but testing. Input which cannot be parsed as a timestamp will throw an exception.

Version 3

UUID UUID::mint( 3, string name, mixed namespace )

Version 3 UUIDs are generated based upon a an MD5 hash of an arbitrary name and its associated name-space. For example the name "www.example.com" is within the DNS namespace, much as "Canada" is within a name-space of the world's countries. A name/namespace pair will predictably generate the same UUID.

The name argument is an arbitrary name and should be in a binary form appropriate for namespace. It is the responsibility of the user to assure the proper conversion to binary form. For many namespaces (like the DNS) the appropriate representation is plain text and therefore no conversion is required.

The namespace argument is itself a UUID; invalid UUIDs will throw an exception.

Note that the continued use of Version 3 UUIDs is discouraged: Version 5 UUIDs should be used instead whenever possible.

Version 4

UUID UUID::mint( 4 )

Version 4 UUIDs are generated from random numbers. Save for embedded version information they are completely random.

Version 5

UUID UUID::mint( 5, string name, mixed namespace )

Version 5 UUIDs are generated based upon a an SHA-1 hash of an arbitrary name and its associated name-space. For example the name "www.example.com" is within the DNS namespace, much as "Canada" is within a name-space of the world's countries. A name/namespace pair will predictably generate the same UUID.

The name argument is an arbitrary name and should be in a binary form appropriate for namespace. It is the responsibility of the user to assure the proper conversion to binary form. For many namespaces (like the DNS) the appropriate representation is plain text and therefore no conversion is required.

The namespace argument is itself a UUID; invalid UUIDs will throw an exception.

Version 5 UUIDs are preferred over Version 3 UUIDs.

UUID UUID::import( string uuid )

The UUID::import() method imports a UUID string as a UUID object. Invalid UUIDs will throw an exception.

bool UUID::compare( mixed uuid1, mixed uuid2 )

The UUID::compare() method compares two UUIDs for equivalency. If both UUIDs, as binary numbers, are equal, the method returns TRUE. The method will also return TRUE if neither arguments is a valid UUID.

This method is useful for determining if two different UUID representations (eg. canonical string, lowercase hex string, uppercase hex string, binary, URN) are in fact the same UUID.

string UUID::mintStr( [int version [, ... ] )

The UUID::mintStr() method performs the same functions as the UUID::mint() method, but returns the UUID directly as a string in canonical form.

bytes

A 16-byte binary string representation of the UUID.

hex

A 32-character hexadecimal representation of the UUID. Neither octets nor fields are ever padded and high digits are always lowercased.

string

The canonical string representation of the UUID, with high hexadecimal digits always lowercased.

urn

The UUID formatted as an URN.

version

The UUID's version (eg. 1, 3, 4, 5).

variant

The UUID's variant. For RFC 4122 UUIDs this is always 1.

node

The MAC address associated with the UUID. Only applicable to Version 1 identifiers.

time

The time at which the UUID was generated, as a fixed-point Unix timestamp string with seven-digit sub-second precision. Only applicable to Version 1 identifiers.

PHP has a number of good sources for random numbers available to it, but most are either system-dependent, incur considerable overhead, or both. Consequently DrUUID uses the mt_rand() function to generate random numbers unless instructed to seek an alternative, usually cryptographically secure source. In order to use an alternative source the UUID::initRandom() static method must be invoked.

int UUID::initRandom( [int source] )

If envoked without arguments, the UUID::initRandom() method will attempt to make use of the best available randomness source; this may nevertheless be mt_rand().

An integer constant, source, may be passed to explicitly choose a source. Passing an unknown value will throw an exception; an exception will also be thrown if an explicitly selected source is not available.

A list of valid source constants is available in Appendix A.

Note that since the characteristics of any given system can be unpredictably different from those of another, users are encouraged to run their own benchmarks to ascertain whether the performance of both UUID::initRandom() and calls thereafter to UUID::randomBytes() warrant an alternative source's use.

For Version 1 UUIDs, a 60-bit timestamp must be generated. On 32-bit systems, this causes PHP to use floating-point arithmetic, which yields inaccurate results, with precision only reliable to the millisecond rather than the microsecond. If either the GMP or BC Math extension is available, or the phpseclib BigInteger class is loaded, DrUUID can make use of any of these to produce accurate results:

int UUID::initBignum( [int means] )

If envoked without arguments, the UUID::initBignum() method will try to use the fastest means of producing accurate timestamps.

An integer constant, means, may be passed to explicitly choose a method. Passing an unknown value will throw an exception; an exception will also be thrown if an explicitly selected method is not available.

A list of valid means constants is available in Appendix A.

On 64-bit systems DrUUID will use accurate arithmetic without having to call UUID::initBignum().

In order to ensure uniqueness of Version 1 UUIDs, the value of the clock sequence, node ID and last timestamp used should be kept in stable storage for reference. By default DrUUID only keeps these values in memory, but they can also be written to a file:

void UUID::initStorage( string path )

DrUUID will read state from and write state to the file specified by path. If the file specified is not accessible, an exception will be thrown. The default implementation will create a file which does not exist, but will not create folders.

If access to a file is either impossible or impractical, an API for implementing a custom storage is described in Section 5. If using custom storage, required arguments may be different.

void UUID::initAccurate( string path )

The UUID::initAccurate() method is a shortcut to achieving optimal accuracy. It successively calls UUID::initBignum(), UUID::initRandom(), and UUID::initStorage(). Unlike calling the three methods by themselves, however, UUID::initAccurate() will reject results which will yield inaccurate UUIDs, and will throw an exception accordingly.

void UUID::registerStorage( string class_name [, mixed arg ... ] )

The class_name argument must be the name of a defined class which imprements the UUIDStorage interface, described below. Any further arguments will be passed to UUID::initStorage().

If no supplementary arguments are passed, UUID::initStorage() must be called before the custom storage may be used.

interface UUIDStorage {
   public function getNode();
   public function getSequence($timestamp, $node);
   public function setSequence($sequence);
   public function setTimestamp($timestamp, $sequence, $node);
   const maxSequence = 16383; // 00111111 11111111
   }

The UUIDStorage interface defines a set of methods which DrUUID will call during the generation of Version 1 UUIDs in a predictable order to query storage and write data. A visualization of the process is available in Appendix C for reference. The order of the method calls is as follows:

1. If a node ID is already available from the user, skip to Step 4
2. Rretrieve the last known node ID (MAC address) by calling getNode()
   • The storage may attempt to retrieve the actual MAC address; otherwise it returns the stored one, or NULL
3. If the node ID is NULL because an existing value is not available, generate a new random node ID
4. If the user has supplied a clock sequence for debugging, call setSequence() and skip to Step 7
5. Retrieve the clock sequence by calling getSequence(), passing the timestamp and node ID
   • The storage invalidates any stored clock sequence if the node ID provided does not match that stored
   • The storage increments the stored clock sequence before returning it if the timestamp provided is older than that stored
6. If the clock sequence is NULL because an existing value was not available or was invalidated, generate a new random clock sequence and call setSequence()
7. Call setTimestamp() to update the stored timestamp, signalling the end of communication

The following subsections serve as implementation notes for the interface's methods.

getNode()

As DrUUID is unable to retrieve the system's MAC address, it calls the getNode() method, which might implement a means of doing so or retrieve one from storage. If it does return a value, it should be formatted as six bytes, in big-endian order (the reverse of conventional hexdecimal pair representation).

getSequence()

The getSequence() method is the heart of the interface, taking as input the target timestamp (as a number of 100ns ticks since the Unix epoch) and the node ID (as a six-byte string). Output should be a two-byte string, with the two most significant bits set to zero.

Per Section 4.1.5 of RFC 4122, the clock sequence should be randomized if the node ID changes, and should be incremented if the target timestamp is lower than that in storage. Due to the limits of 32-bit systems and the difficulties inherent in comparing floating-point numbers, the input timestamp is always a string with integer precision.

setSequence()

This method simply alerts the storage of a new clock sequence, if either the user has supplied a sequence or the storage failed to return a result. Input is a two-byte string; no return value is required.

setTimestamp()

The method serves as a marker that communication with the storage is complete and any buffered data may be written to stable storage if appropriate. Input is a string representation of the number of 100ns ticks since the Unix epoch.