[erlang-questions] [ANN] Erlang UUID

[Michael Truog]

On 02/26/2012 04:38 AM, Per Andersson wrote:
> On Thu, Feb 23, 2012 at 2:28 PM, Fred Hebert <mononcqc@REDACTED> wrote:
>> Any advantage or differences compared to https://github.com/okeuday/uuid
> Erlang UUID follows RFC 4122 with creation of UUID v1, using IEEE 802 node
> adress.
>
> >From my personal point of view Erlang UUID has more readable code.

I thought I should add more detail to this comparison.  It makes more sense to compare https://github.com/okeuday/uuid and http://github.com/avtobiff/erlang-uuid, since both are native Erlang code (https://github.com/yrashk/erlang-ossp-uuid is a NIF integrating with the C library, as was previously mentioned).

1) "okeuday/uuid" v1 is Erlang pid specific.  It follows the RFC 4122, but just adds some extra information to the node id.  Most people have agreed, after the RFC was created, that using a MAC address as the only indication of uniqueness related to the code's runtime (i.e., in addition to time and a small random number) is a bad idea.  So, the "okeuday/uuid" v1 combines the distributed Erlang node name, with the MAC address, and the Erlang pid indexes, using crypto:sha/1 and bitwise-xor operations (which are non-destructive).  So, this implementation approach is unique to Erlang, but is able to provide a unique identifier for the Erlang pid, at a certain point in time.  The "avtobiff/erlang-uuid" code just uses the MAC address for the node id within the v1.  Please also remember that the function to retrieve the MAC address from within Erlang is undocumented, and "okeuday/uuid" v1 does not depend on an interface being available (i.e., for the MAC address) while
"avtobiff/erlang-uuid" v1 will attempt to use random:uniform/1 to create more than 44bits of randomness if no interface is available.

2) There is an important problem within "avtobiff/erlang-uuid" for v4, since random:uniform/1 only provides 44 bits of randomness, if you are lucky (that is probably pushing it, since the algorithm may have been meant to only provide 32 bits), however, the v4 function is attempting to use random:uniform/1 to provide 48 bits and 62 bits, where the rest should become 0 because of the algorithm used by random:uniform/1.  The other problem with v4 is that it reseeds random:uniform/1 each time the function is called with erlang:now(), which creates additional latency and possibly makes the v4 uuid less-random (depending on how it is called, e.g., on a timer).  To see a better implementation for v4, using random:uniform/1, there is get_v4_urandom_bigint/0 and get_v4_urandom_native/0 in "okeuday/uuid", however, both solutions become slower in testing when compared with get_v4/0 which uses crypto:rand_bytes/1 instead of multiple calls to random:uniform/1.

3) The other important difference is the license.  "avtobiff/erlang-uuid" is under a GPLv3 license, while "okeuday/uuid" is under a BSD license.  So, there is nothing blocking the commercial use of "okeuday/uuid" (please remember I am not a lawyer, nor am I giving legal advice).

I think "okeuday/uuid" has more readable code, but I am also biased.  That judgment is subjective, so it doesn't really relate to the performance or usability of the uuid code.

> All in all, no revolutionary differences.

I would agree that there are not many differences, in the sense that both pieces of code are based on the same RFC.  However, I do think there are severe differences in both the performance and usability, based on the implementation decisions.

- Michael