in reply to MD5-based Unique Session ID Generator

If you don't mind using 128 bits rather than 32, Data::UUID guarantees that you won't get duplicates, ever. 

  use Data::UUID;
  use constant IDGenerator => Data::UUID->new();

  sub new_sid { IDGenerator->create() }

[download]

Update: Duh, they're both the same size, 128 bits and 32 hex digits.

Replies are listed 'Best First'.
Re^2: MD5-based Unique Session ID Generator
by hardburn (Abbot) on Aug 19, 2004 at 20:50 UTC

    MD5 is 128 bits. It's 32 hex digits.

    I do prefer Data::UUID for this task, myself. Note that while it guarantees uniqueness, it doesn't guarantee unpredictibility, which may or may not be a problem for a given application. Most MD5/SHA1/whatever session generators have the same issue.

    "There is no shame in being self-taught, only in not trying to learn in the first place." -- Atrus, Myst: The Book of D'ni.

[reply]
Re^2: MD5-based Unique Session ID Generator
by radiantmatrix (Parson) on Aug 19, 2004 at 20:46 UTC
    If you don't mind using 128 bits rather than 32, Data::UUID guarantees that you won't get duplicates, ever.

    Thanks! I won't be able to test this immediately, but if it works (and it seems like it will), it will be most helpful.

    One point though, MD5 generates 32 hex digits representing 4 bits each - that's already 128 bits. Sorry if I was unclear about that.

[reply]
Re^2: MD5-based Unique Session ID Generator
by adrianh (Chancellor) on Aug 21, 2004 at 12:35 UTC
    Data::UUID guarantees that you won't get duplicates, ever.

    While Data::UUID is a good solution, it doesn't guarantee that "you won't get duplicates, ever" (heck - there are only 128bits after all :-)

    As the docs say...

    A UUID is 128 bits long, and is guaranteed to be different from all other UUIDs/GUIDs generated until 3400 CE.

    ...

    It provides reasonably efficient and reliable framework for generating UUIDs and supports fairly high allocation rates -- 10 million per second per machine -- and therefore is suitable for identifying both extremely short-lived and very persistent objects on a given system as well as across the network.

    So, it wouldn't be suitable if you were coding something up for The Long Foundation - or needed to allocate UUIDs really, really, really quickly :-)

    The full gory detail can be found in this IETF draft.

    All this complexity is, of course, why I like Data::UUID. People who are experts have taken the time to look hard at the algorithm, and I can have some confidence in it working well.

[reply]
      While Data::UUID is a good solution, it doesn't guarantee that "you won't get duplicates, ever" (heck - there are only 128bits after all :-) ... A UUID is 128 bits long, and is guaranteed to be different from all other UUIDs/GUIDs generated until 3400 CE.

      I didn't say "it will never produce duplicates" -- just that "YOU won't get duplicates" (unless you live for over a thousand years).

[reply]
        I didn't say "it will never produce duplicates" -- just that "YOU won't get duplicates" (unless you live for over a thousand years)

        You mean you're not planning to?

        I fully intend to be scanned and on CPAN as JAPH::ADIE when the singularity hits (probably initiated by the release of Perl 6 into the wild :-)

[reply]

In Section Cool Uses for Perl