Forum: Ruby on Rails uuidtools across processes

Announcement (2017-05-07): www.ruby-forum.com is now read-only since I unfortunately do not have the time to support and maintain the forum any more. Please see rubyonrails.org/community and ruby-lang.org/en/community for other Rails- und Ruby-related community platforms.
F641ba2e0fc906fb77d74b52cf59d187?d=identicon&s=25 Doug Dupory (doug)
on 2006-04-04 07:40
Hello,

It seems that there is a small probability of collisions among uuid's
produced by uuidtools' UUID.random_create() running in concurrent user
processes on a host (fcgi)? The ~2 bytes extracted from the randomized
clock_sequence make a collision unlikely.

http://rubyforge.org/frs/download.php/8572/uuidtoo...

Do I miss something?

DD
59de94a56fd2c198f33d9515d1c05961?d=identicon&s=25 Tom Mornini (Guest)
on 2006-04-04 08:06
(Received via mailing list)
On Apr 3, 2006, at 10:40 PM, Doug Dupory wrote:

> It seems that there is a small probability of collisions among uuid's
> produced by uuidtools' UUID.random_create() running in concurrent user
> processes on a host (fcgi)? The ~2 bytes extracted from the randomized
> clock_sequence make a collision unlikely.

It also relies on true_random, which it claims is a very good random
number generator "much, much better than the built-in pseudorandom
number
generators".

Since it doesn't appear to use PIDs after a cursory glance, I'd say
you're correct.

Particularly so if it's running on multiple hosts, because that routine
doesn't appear to reference MAC address, making collisions that much
more
likely, if ever so rare.

--
-- Tom Mornini
Be09addcbb47f2a684fa5c48bac94149?d=identicon&s=25 David Johnson (Guest)
on 2006-04-04 14:06
(Received via mailing list)
This is a good catch.  Someone (possibly me) will need to delve into the
code and see if it can be patched to reference the MAC address
appropriately.
F641ba2e0fc906fb77d74b52cf59d187?d=identicon&s=25 Doug Dupory (doug)
on 2006-04-04 19:24
Tom Mornini wrote:
> On Apr 3, 2006, at 10:40 PM, Doug Dupory wrote:
>
>> It seems that there is a small probability of collisions among uuid's
>> produced by uuidtools' UUID.random_create() running in concurrent user
>> processes on a host (fcgi)? The ~2 bytes extracted from the randomized
>> clock_sequence make a collision unlikely.
>
> It also relies on true_random, which it claims is a very good random
> number generator "much, much better than the built-in pseudorandom
> number generators".

The concern is that "only" 14 bits of this true_random (assigned to
clock_sequence) is used. The probability of collisions in a fcgi
configuration is a little too likely. Plus the potential MAC issue, an
exception code better be in place to re-generate uuid's.

It would be better if uuidtools' code were run in the kernel space,
rather than the user. Or, it embeds a PID in uuid's.

Another approach is to get uuid's from a database, i.e. MySQL's UUID(),
as long as one DB server runs on a host, effectively making the DB
server the kernel for all its client processes. However, if MySQL forks
a user process for each client, not create a pthread, we're back to
square one. Is this the case? Any other downsides?

DD
This topic is locked and can not be replied to.