commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Steve Downey" <steve.dow...@geowealth.com>
Subject Re: UUID Reuse proposal
Date Sat, 16 Aug 2003 03:29:52 GMT
That's not good, since your fake MAC address could conflict with someone
else's real MAC address. If you're going to use random numbers for UUIDs,
you need to change the version field, also.

    -SMD
----- Original Message -----
From: "Tim Anderson" <tma@netspace.net.au>
To: "Jakarta Commons Developers List" <commons-dev@jakarta.apache.org>
Sent: Friday, August 15, 2003 10:37 PM
Subject: RE: UUID Reuse proposal


> The Tyrex implementation doesn't attempt to get the
> MAC address from the system, but loads it from a configuration
> file.
> If the address isn't configured, it falls back to using
> a random no. for the MAC address.
>
> -Tim
>
> > -----Original Message-----
> > From: Steve Downey [mailto:steve.downey@geowealth.com]
> > Sent: Saturday, 16 August 2003 12:26 PM
> > To: Jakarta Commons Developers List
> > Subject: Re: UUID Reuse proposal
> >
> >
> > I've posted a version of a UUID class previously that meets the random
> > number version of the leech spec.
> >
> > Getting MAC addresses portably is mildly difficult, and requires
> > root access
> > on most systems. Using a cryptographically good random number
> > generator is a
> > reasonably good alternative, and if done right, won't collide
> > with the UUIDs
> > generated using MAC addresses.
> >
> > I've used them heavily for synthetic primary keys in database tables.
> >
> > If there's interest, I could repost the class.
> >
> >     -SMD
> > ----- Original Message -----
> > From: "Phil Steitz" <steitzp@yahoo.com>
> > To: "Jakarta Commons Developers List" <commons-dev@jakarta.apache.org>;
> > <tma@netspace.net.au>
> > Sent: Friday, August 15, 2003 7:11 PM
> > Subject: RE: UUID Reuse proposal
> >
> >
> > > Having looked now at both implementations (assuming the axis impl is
> > what's
> > > in CVS at
> > >
> > http://cvs.apache.org/viewcvs.cgi/xmlaxis/java/src/org/apache/axis
> > /component
> > s/uuid/),
> > > I agree that the tyrex implementation is better for two reasons:
> > >
> > > 1. It appears to be threadsafe.
> > >
> > > 2. It allows the node ID to be read from a properties file
> > (getting around
> > > the inaccessability of the MAC address in Java).
> > >
> > > The axis implementation uses random bits from a SecureRandom
initialized
> > in
> > > a static initialization block for the node ID. I don't see the big
value
> > in
> > > a UUID implementation that uses random bits for the node ID.  While
you
> > can
> > > get very low probability of collision like this, it is no longer
> > > guaranteed, so why not just use a purely random string (which
> > lang already
> > > has in RandomStringUtils)?  The only value that remains in the UUID
> > > algorithm when you remove the "U" is that it is a standard and you can
> > > decompose it into the time bits and the node bits.
> > >
> > > I do like the idea of lang providing a home for
> > "IdentifierUtils" suitably
> > > named and packaged.  There are really multiple types here:
> > >
> > >  * UUID (pseudo) standard, non-random, non-secure
> > >  * Random, non-secure, not guaranteed unique (e.g. RandomStringUtils)
> > >  * Random, "secure", not guaranteed unique (e.g. Tomcat session IDs)
> > >  * Part random, "secure", guaranteed unique (what Tomcat really
> > needs ;-)
> > >  * Bounded sequential(e.g. Betwixt's io identifiers)
> > >  * Cyclic
> > >
> > > I am still +1 for including a good implementation of the UUID
> > pseudo-spec.
> > > Starting with the tyrex base would probably be easier; but we could
> > > certainly just add the necessary features to the axis impl.
> > >
> > > Phil
> > >
> > >
> > > --- Tim Anderson <tma@netspace.net.au> wrote:
> > > > Tyrex also provides support for UUID generation, and
> > > > should perform better than the Axis impl.
> > > >
> > > > See
> > > >
> > >
> > http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/tyrex/tyrex/src/mai
> > n/tyrex/se
> > > > rvices/UUID.java?rev=1.6
> > > >
> > > > -Tim
> > > >
> > > > > -----Original Message-----
> > > > > From: Tim Reilly [mailto:tim.reilly@consultant.com]
> > > > > Sent: Friday, 15 August 2003 11:32 AM
> > > > > To: axis-dev@ws.apache.org; commons-dev@jakarta.apache.org
> > > > > Subject: UUID Reuse proposal
> > > > >
> > > > >
> > > > > I'd like to ask the axis developers to donate the java package
> > > > > org.apache.axis.components.uuid to the Jakarta commons.
> > > > >
> > > > > I'm cross-posting this message on both jakarta commons-dev list
> > > > > and axis-dev
> > > > > list as commons could adopt this package and place somewhere
> > > > > sensible to the
> > > > > commons. My suggestion would be as an addition to
> > > > org.apache.commons.lang
> > > > > since the UUID is a special/complex type (aren't all classes, but
> > > > > hopefully
> > > > > you know what I'm saying.)
> > > > > I know not to cross-post but given the request it only
> > makes sense. I
> > > > > realize the package has some basis on the similar package in the
BSD
> > > > > licensed http://sourceforge.net/projects/juddi/ project. It
doesn't
> > > > make
> > > > > sense to include the UUIDGenFactory, which would remain in place
> > > > (unless
> > > > > anyone has good ideas on making it more generic?)
> > > > >
> > > > > The reason for this request is that the package is nicely written
> > > > > (kudos to
> > > > > the author(s)), and very useful in a number of applications. The
> > > > Jetspeed
> > > > > developers can use this package; however it does not necessarily
> > > > > make sense
> > > > > for Jetspeed to create a dependency on the axis jar, solely to use
> > this
> > > > > package. There are numerous other applications of UUID's
> > that make it
> > > > an
> > > > > ideal candidate for the Jakarta-commons, and I feel that
> > > > donating/adopting
> > > > > this package within the commons fits nicely with the vision of
> > > > > the commons.
> > > > > Other uses abound, for example struts could use the classes to
> > > > guarantee a
> > > > > form is submitted only once. A search of theserverside.com brings
> > > > > back some
> > > > > patterns that use guid/uuid.
> > > > >
> > > > > I'd be willing to send the patches to the Axis team if the commons
> > > > > committers are willing to adopt the package and Axis wishes
> > the same.
> > > > > Basically this would be to depreciate
> > > > > org.apache.axis.components.uuid.SimpleUUID and make
> > SimpleUUID extend
> > > > > org.apache.commons.lang.UUID.SimpleUUID (tentative). Then
> > replace the
> > > > > "org.apache.axis.components.uuid.SimpleUUID" strings within the
CVS.
> > Or
> > > > if
> > > > > there is a better way.. I'd be will to do whatever is agreed upon.
> > > > >
> > > > > Please consider this request; I'll keep an eye on each list and if
> > both
> > > > > projects agree that would be great and we can proceed.
> > > > > A lesser alternative would be for jakarta-commons to adopt the
> > > > > package, but
> > > > > axis makes no changes. This is the perhaps the lesser approach
since
> > > > reuse
> > > > > is not fully accomplished but if the Axis committers are reluctant
> > then
> > > > > perhaps they could give their "okays" to the lesser approach, and
> > > > > jakarta-commons could still adopt the classes.
> > > > >
> > > > > For more information on UUID:
> > > > > Per javadoc comment -
> > > > > * A Universally Unique Identifier (UUID) is a 128 bit
> > number generated
> > > > > * according to an algorithm that is guaranteed to be unique in
time
> > and
> > > > > space
> > > > > * from all other UUIDs. It consists of an IEEE 802 Internet
Address
> > and
> > > > > * various time stamps to ensure uniqueness. For a complete
> > > > specification,
> > > > > * see
> > > > >
> > ftp://ietf.org/internet-drafts/draft-leach-uuids-guids-01.txt [leach].
> > > > >
> > > > > Thank you for considering.
> > > > > -Tim Reilly
> > > > >
> > > > >
> > > > >
> > ---------------------------------------------------------------------
> > > > > To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
> > > > > For additional commands, e-mail:
commons-dev-help@jakarta.apache.org
> > > > >
> > > > >
> > > >
> > > >
> > > >
> > >
> ---------------------------------------------------------------------
> > > > To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
> > > > For additional commands, e-mail: commons-dev-help@jakarta.apache.org
> > > >
> > >
> > >
> > > __________________________________
> > > Do you Yahoo!?
> > > Yahoo! SiteBuilder - Free, easy-to-use web site design software
> > > http://sitebuilder.yahoo.com
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
> > > For additional commands, e-mail: commons-dev-help@jakarta.apache.org
> > >
> > >
> > >
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
> > For additional commands, e-mail: commons-dev-help@jakarta.apache.org
> >
> >
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: commons-dev-help@jakarta.apache.org
>
>
>


Mime
View raw message