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/uuidtools-1.0.0.zip Do I miss something? DD -- Posted via http://www.ruby-forum.com/.
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
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. On Mon, 2006-04-03 at 23:03 -0700, 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". > > 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 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 -- Posted via http://www.ruby-forum.com/.