Hi, I need to generate unique long ID for each client which will be transported from server to client and vise versa . As I see, J2SE has the next classes which may be useful to me: Random and SecureRandom.
What and why is better to use? Maybe it is better use another class or maybe external library? May you give me an advise. May you also give a link to specific article if you know. Thank you in advance.
Is there a security issue? If so, use SecureRandom.nextLong(). Otherwise is there anything wrong with sequential IDs? It's a lot simpler:
static long nextID = 0;
public static synchronized getNextID()
{
return nextID++; // or ++nextID
}
> timestamp in milliseconds multiplied by the hashcode
> of the userid and then multiplied by the numeric
> representation of the ip address of the server should
> be unique enough.
Or he could just use SecureRandom, which is simple, compact, and more standard, and has more inputs.
> > timestamp in milliseconds multiplied by the
> hashcode
> > of the userid and then multiplied by the numeric
> > representation of the ip address of the server
> should
> > be unique enough.
>
> Or he could just use SecureRandom, which is simple,
> compact, and more standard, and has more inputs.
And how unique would those be in a clustered environment?
public class UniqueID {
static long current= System.currentTimeMillis();
static public synchronized long get(){
return current++;
}
}
> > > timestamp in milliseconds multiplied by the
> > hashcode
> > > of the userid and then multiplied by the numeric
> > > representation of the ip address of the server
> > should
> > > be unique enough.
> >
> > Or he could just use SecureRandom, which is
> simple,
> > compact, and more standard, and has more inputs.
>
> And how unique would those be in a clustered
> environment?
Probably at least as unique as the solution proposed above.
> public class UniqueID {
>static long current= System.currentTimeMillis();
> static public synchronized long get(){
>return current++;
> }
> }
As long as it doesn't have to be unique across hosts, JVM invocations, or multiple copies of that class loaded into the same VM, and as long as its okay for a client to guess other clients' IDs simply by adding to or subtracting from his own.
> > > > timestamp in milliseconds multiplied by the
> > > hashcode
> > > > of the userid and then multiplied by the
> numeric
> > > > representation of the ip address of the server
> > > should
> > > > be unique enough.
> > >
> > > Or he could just use SecureRandom, which is
> > simple,
> > > compact, and more standard, and has more inputs.
> >
> > And how unique would those be in a clustered
> > environment?
>
>
> Probably at least as unique as the solution proposed
> above.
why do you think I hashed the IP address of the server into the ID :)
http://java.sun.com/j2se/1.5.0/docs/api/java/security/SecureRandom.html:
'A cryptographically strong random number minimally complies with the statistical random number generator tests specified in FIPS 140-2, Security Requirements for Cryptographic Modules, section 4.9.1. Additionally, SecureRandom must produce non-deterministic output and therefore it is required that the seed material be unpredictable and that output of SecureRandom be cryptographically strong sequences as described in RFC 1750: Randomness Recommendations for Security.'
You could use the IP address, system time, workstation ID, process #, etc in the initial seed if you insist. But even without it, SecureRandom is by far the strongest solution available.
