Impressive. Could you make a small modification and run the same test with 20 concurent threads ? I checked the code and we have plenty of syncs, but you never know.
Interesting - java.util.Random is not synchronized, so it is very likely that 2 threads calling the method at the same time will get a collision. java.security.SecureRandom seems ok. Most random sources use some "natural" entropy ( time, number of interrupts, etc ) and some alghoritm to derive the next number. If 2 calls are too close to each other, we'll not have enough entropy and without the right synchronization you may get the same result ( if the seed wasn't updated ). I did check the code and it looks ok - plenty of synchronized() blocks. But who knows ? Costin Phil Steitz wrote: > Using a modified version of Tim Funk's "Collide.java", I ran the > following dispersion test (using Sun's Linux jdk's 1.3.1_03 and 1.4.1_01): > > 1. Generate n session id's. > 2. For each pair of generated id's, count the number of matching > characters in the two strings (i.e., the number of positions where the > hex digits are the same). > 3. Compare the distribution of matches to the binomial distribution > B(16,1/16). > > The results of one run of 10000 (using 1.4.1_01) are attached (along > with the code). They show close agreement with the expected > distribution. I did several runs with 10-30k sample sizes. Of course, > this doesn't *prove* anything; but it does support the hypothesis that > p(exact match among two session IDs) ~ 1/2^128. -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
