[erlang-questions] [ANN] Erlang UUID

[Per Andersson]

On Sun, Feb 26, 2012 at 9:53 PM, Michael Truog <mjtruog@REDACTED> wrote:
> 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).

Yes, I was not exactly clear about this but that is what I meaned.
Thanks for the clarification!


> 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.

Correct observation.


> Please also remember that the function to retrieve the MAC address from within Erlang is undocumented,

The function to retrieve MAC address from Erlang is not
undocumented anymore.

    [0] http://www.erlang.org/doc/man/inet.html#getifaddrs-0


> 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.

Thanks for the comments on this. Erlang UUID no longer uses
random:uniform/1 to create anymore than 32 bits of random
data.

However, how do you deduce that random:uniform/1 only provides
44 bits of random data? Since a float is returned from random:random/0
which is used by random:uniform/1, isn't the total random bits 16 or 24
(4 and 3 words on 32-bit and 64-bit architectures respectively)?

    [1] http://www.erlang.org/doc/efficiency_guide/advanced.html#id68291


> 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).

It is of course entirely possible to develop commercial applications with
GPL'd software. What you can't do is to transform free software into
proprietary software.


> 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.

It is a subjective measure. However relevant for extendability
(which would fall in the usability category).


>> 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.

That might be so. Thank you for your evaluation.


--
Per

> - Michael
>