We have used the following algorithm for getting prefix:
ServerSocket sk = new ServerSocket(0);
long time = System.currentTimeMillis();
short port = (short)sk.getLocalPort(); // it really short for now, do
not know about ip6
InetAddress ip = InetAddress.localHost();
sk.close()
byte prefix[] = concat(bytes(time),bytes(port),ip.getAddress());
size = 8+2+4 = 14 bytes = 112 bits
Then UUID may be got by adding short counter. If you run out of
shorts you may regenerate prefix.
The number will be likely unique if we assume ipaddress is unique
(or at least we may run uuid service on server with real ip address).
There can only one server socket for given time on the given port
(if we do not use shared server sockets).
Constantine
James Cook wrote:
>
> Point taken. MessageDigest would be better, and the more bits you have
> available (128 vs 32) is the critical factor in determining uniqueness.
>
> I did find an Internet draft for guidelines on the generation of UUIDs.
> http://www.microsoft.com/dtv/draft-leach-uuids-guids-01.txt
>
> The UUID schema suggested is also 128-bit for sufficient uniqueness. The
> problem I see with 128-bit numbers involves their representation in the
> database. This large of a value, may have to be represented with a String
> type to achieve the proper precision.
>
> The original mechanism that I suggested in the EJB involved three integers
> that can be guaranteed to be unique. Perhaps there is an efficient and
> reliable way to combine these three integers to represent a *sufficiently*
> unique number. Perhaps there isn't. Maybe, going to a 64-bit long value
> would be more appropriate.
>
> If all else fails, we can get rid of the timestamp parameter, and simply
> keep a sequence number. This sequence number will be incremented on each
> call to getUID() and persisted in the ejbActivate and ejbPassivate methods.
> I was hoping to avoid this persistence step. Some containers that I have
> used, call these methods after every transaction!
>
> Since this is an EJB group, I don't want to get too far off-topic by
> focusing on the algorithm. I believe that every implementation that uses
> some kind of crunching algorithm (non-sequential) will have to handle the
> possibility of a duplicate key being generated.
>
> jim
>
> ----- Original Message -----
> From: Mats Lofkvist <[EMAIL PROTECTED]>
> To: <[EMAIL PROTECTED]>
> Sent: Thursday, July 29, 1999 9:59 AM
> Subject: Re: UUID Implementation (correction of my earlier post)
>
> > Mats,
> >
> > I don't think your previous post made it through...
> >
> > jim
> >
> > Hmm, if not then I get another try (if somebody removes posts with
> > errors I hope I have better luck with this one :-)
> >
> > The suggested algorithm was:
> >
> > 1. Split a timestamp (long) into two int's.
> > 2. Increment a sequence counter (int).
> > 3. Use the java.util.zip.CRC32 class to generate a CRC value for
> > these 3 integer values.
> > 4. Return this value.
> >
> > The returned crc32 is 32 bit number as far as I know.
> > This is way to small since the risk of having generated two identical
> > id's reach 50% after only 2^16 id's (due to the birthday paradox).
> >
> > Even if the crc32 returns a full long, the risk of duplicates may be
> > to big to ignore if you are creating large numbers of id's.
> >
> > My suggestion is to replace the crc32 with a hash from
> > java.security.MessageDigest. Those are 128 bits or more.
> >
> > _
> > Mats Lofkvist
> > [EMAIL PROTECTED]
> >
> >
> ===========================================================================
> > To unsubscribe, send email to [EMAIL PROTECTED] and include in the
> body
> > of the message "signoff EJB-INTEREST". For general help, send email to
> > [EMAIL PROTECTED] and include in the body of the message "help".
> >
> >
>
> ===========================================================================
> To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
> of the message "signoff EJB-INTEREST". For general help, send email to
> [EMAIL PROTECTED] and include in the body of the message "help".
===========================================================================
To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
of the message "signoff EJB-INTEREST". For general help, send email to
[EMAIL PROTECTED] and include in the body of the message "help".
