VMID.... how unique is it?
Martin Tilma
java.rmi.dgc.VMID
how unique is it ? what happens when the virtual machine restarts ? is it
posible that VMID not unique is? Does is works like the same way as session
id's genereated by webservers ?
J. S. Jensen
VMID is quite unique. No, it does /not/ act as a session key. It is a
concatenation of several variables that make it damn-near impossible to
get a collision. A rolling sequence number rolls a timer, which is bound
by a JVM invocation ID as well as a unique host ID.
--
J. S. Jensen, Cu.H.
mailto:jsje...@saba.com
http://www.saba.com
Mark Thornton
"J. S. Jensen" <jsje...@bastion.pic.cat.com> wrote in message
news:ae52rf$147$1...@news.cat.com...
> In comp.lang.java.programmer Martin Tilma <in...@t4is.nl> wrote:
>
> > java.rmi.dgc.VMID
> > how unique is it ? what happens when the virtual machine restarts ? is
it
> > posible that VMID not unique is? Does is works like the same way as
session
> > id's genereated by webservers ?
>
> VMID is quite unique. No, it does /not/ act as a session key. It is a
> concatenation of several variables that make it damn-near impossible to
> get a collision. A rolling sequence number rolls a timer, which is bound
> by a JVM invocation ID as well as a unique host ID.
>
For a weak interpretation of unique: just start two or more JVMs at about
the same time, running the same application. This is easier to do on a
multiprocessor machine. You could even get a clash on two different machines
if they have the same IP address (e.g. on private address ranges,
communicating via NAT routers). Again you need to start the two machines at
the same time. In this context same time means any time where
System.currentTimeMillis gives the same value, which in the case of my own
machine requires a match to within the 15ms clock resolution.
So deliberately creating two JVM with an identical VMID value would be
rather easy (especially on a dual processor machine like mine). The chance
of duplicates arising by chance is more difficult to assess but is certainly
not zero.
The various 'unique' id values found in java.rmi.* are probably adequate
when used in the context of rmi, but are not suitable for more general
use --- the uniqueness guarantee and conditions are just too weak.
Mark Thornton
J. S. Jensen
> For a weak interpretation of unique: just start two or more JVMs at about
> the same time, running the same application. This is easier to do on a
> multiprocessor machine.
Theoretically weak, yes, but realistically quite good:
Here's my result on a /fast/ multiprocessor machine:
$ cat <<EOF >ID.java
public class ID {
public static void main(String[] argv) {
System.out.println(new java.rmi.dgc.VMID().toString());
}
}
EOF
$ javac ID.java && ( java ID & java ID & java ID &
java ID & java ID & java ID &
java ID & java ID & java ID &
java ID & java ID & java ID ) |
sort |uniq -c
1 0ac097e1f9f0db55:2457b6:ee6024c6bd:-8000
1 0ac097e1f9f0db55:30f13d:ee6024c7f2:-8000
1 0ac097e1f9f0db55:30f13d:ee6024c862:-8000
1 0ac097e1f9f0db55:30f13d:ee6024c8fc:-8000
1 0ac097e1f9f0db55:4b222f:ee6024c4de:-8000
1 0ac097e1f9f0db55:4b222f:ee6024c707:-8000
1 0ac097e1f9f0db55:4b222f:ee6024c70e:-8000
1 0ac097e1f9f0db55:4b222f:ee6024c7d9:-8000
1 0ac097e1f9f0db55:4b222f:ee6024c7f3:-8000
1 0ac097e1f9f0db55:4b222f:ee6024c853:-8000
1 0ac097e1f9f0db55:4b222f:ee6024c89a:-8000
1 0ac097e1f9f0db55:4b222f:ee6024c8b6:-8000
Which, granted, produces some interesting second field results, but I can't
get any duplicates, even on the same machine.
$ ( seq 100 |while read ; do java ID & done ) |sort |uniq -c
doesn't even produce duplicates, though a LOT of mem usage :-)
> So deliberately creating two JVM with an identical VMID value would be
> rather easy
Can you physically get them? Even in very extensive testing, I've not
been able to get reproduction.
Mark Thornton
> In comp.lang.java.help Mark Thornton <mtho...@optrak.co.uk> wrote:
>
> > For a weak interpretation of unique: just start two or more JVMs at
about
> > the same time, running the same application. This is easier to do on a
> > multiprocessor machine.
>
> Theoretically weak, yes, but realistically quite good:
>
> Here's my result on a /fast/ multiprocessor machine:
>
My poor old home machine is neither fast nor dual processor, but it gets
results closer together than yours (not my results were triggered in pairs)
500b24cdc3cc1ce0:2dacd1:ee60def6d0:-8000
500b24cdc3cc1ce0:2dacd1:ee60def749:-8000
500b24cdc3cc1ce0:2dacd1:ee60e0a4ac:-8000
500b24cdc3cc1ce0:2dacd1:ee60e0a539:-8000
My home machine is simply not fast enough to execute the two VMID methods
within the same time slot. I'll try it at work tomorrow (Dual P3/1GHz
instead of a P2/400MHz).
Perhaps my biggest gripe with VMID is that UUID already existed (in the OS
on most current systems and can be implemented on any that don't) and
provide a far better guarantee of uniqueness. VMID stinks as a bad case of
NIH syndrome (Not Invented Here).
I notice the JINI does use UUID.
//----------------------------
import java.rmi.dgc.VMID;
class IDTest
{
public static void main(String[] args)
{
long t0 = System.currentTimeMillis();
try {
Thread.sleep((int)(10000 - t0%10000));
}
catch (InterruptedException ex) {
}
t0 = System.currentTimeMillis();
VMID id = new VMID();
long t1 = System.currentTimeMillis();
System.out.println(id+", date="+t0+", delta="+(t1-t0));
}
}
J. S. Jensen
> Perhaps my biggest gripe with VMID is that UUID already existed
Are you talking about the org.w3c.util.UUID or something else?
> (in the OS on most current systems and can be implemented on any that
> don't) and provide a far better guarantee of uniqueness.
> VMID stinks as a bad case of NIH syndrome (Not Invented Here).
Yeah, but it's in the java.* package and quite easy to find at my clients'
sites ;-)
--
J. S. Jensen, Cu.H.
Mark Thornton
"Mark Thornton" <m.p.th...@ntlworld.com> wrote in message
news:ae5njq$46kpe$1...@ID-139894.news.dfncis.de...
>
> "J. S. Jensen" <jsje...@bastion.pic.cat.com> wrote in message
> news:ae5b50$1hc$1...@news.cat.com...
> > In comp.lang.java.help Mark Thornton <mtho...@optrak.co.uk> wrote:
> >
> > > For a weak interpretation of unique: just start two or more JVMs at
> about
> > > the same time, running the same application. This is easier to do on
a
> > > multiprocessor machine.
> >
> > Theoretically weak, yes, but realistically quite good:
> >
> > Here's my result on a /fast/ multiprocessor machine:
> >
>
> within the same time slot. I'll try it at work tomorrow (Dual P3/1GHz
> instead of a P2/400MHz).
Succeeded at the first attempt just manually executing the code in two
separate command windows.
0ca90af595c8e18a:2dacd1:ee634ee04c:-8000, date=1023868329998, delta=62
0ca90af595c8e18a:2dacd1:ee634ee04c:-8000, date=1023868329998, delta=62
Mark Thornton
Mark Thornton
> In comp.lang.java.programmer Mark Thornton <m.p.th...@ntlworld.com>
wrote:
>
> > Perhaps my biggest gripe with VMID is that UUID already existed
>
> Are you talking about the org.w3c.util.UUID or something else?
>
Where did you find that implementation? UUID (sometimes known as GUID) are
implemented in the operating system on Windows, many Unices and other
systems. They are a 16 byte unique value (usually) based on a MAC address as
well as the current time. If the MAC| address is used they are guarantee
unique (no ifs or buts) until far into the future (when the time wraps
around).
http://developer.java.sun.com/developer/bugParade/bugs/4173528.html
> Yeah, but it's in the java.* package and quite easy to find at my clients'
> sites ;-)
True, but my contention is that it should never have been written and a
proper UUID should have been written instead.
Mark Thornton
Mark Thornton
> In comp.lang.java.programmer Mark Thornton <m.p.th...@ntlworld.com>
wrote:
>
> > Perhaps my biggest gripe with VMID is that UUID already existed
>
> Are you talking about the org.w3c.util.UUID or something else?
org.w3c.util.UUID is something different (it is very similar to VMID). Like
VMID it assumes the uniqueness of network addresses (maybe when IPv6 is in
widespread use that will work), and that you aren't running many
simultaneous VMs on the same machine.
Mark Thornton
J. S. Jensen
> Succeeded at the first attempt just manually executing the code in two
> separate command windows.
> 0ca90af595c8e18a:2dacd1:ee634ee04c:-8000, date=1023868329998, delta=62
> 0ca90af595c8e18a:2dacd1:ee634ee04c:-8000, date=1023868329998, delta=62
???
I have several quad proc Sun machines, a couple dual proc Linux boxen and
can't get em to duplicate.
Anything in particular you did?
--
J. S. Jensen, Cu.H.
Mark Thornton
"J. S. Jensen" <jsje...@might.saba.com> wrote in message
news:3d0a...@news.mhogaming.com...
Note that my code includes a delay to the next 10 second multiple. To
execute the code I just opened two command windows in the appropriate
directory and typed "java IDTest" in each one (but didn't return). Then I
typed return at one and quickly switched to the other and typed return there
too. Voila, both windows come up with the same ID value. This tedious manual
starting is due to the inadequacies of the standard Windows command
processor.
My machine is a Dual P3/1GHz, 256MB running Windows 2000 SP2, Java 1.4.0.
The system timing resolution is approximately 15.6ms.
What is the system clock resolution on your Unix boxes?
Given the time taken to obtain a VMID (~62ms @ 1GHz), a single 2.5GHz P4
running Windows 9x (clock resolution 55ms) might just be able to issue two
identical VMID.
Mark Thornton
J. S. Jensen
> What is the system clock resolution on your Unix boxes?
I just tested my Linux server box, and I can't get any delta on repeated
System.currentTimeMillis() less than 10ms. I'll try on the Sun systems
later today.
> Given the time taken to obtain a VMID (~62ms @ 1GHz), a single 2.5GHz P4
You mean through a new VMID().toString()? Look at the following and
it at least `seems' as though it takes a heck of a lot less than ~62ms
to generate the VMID (at least in the same VM). I don't know much about
the intel procs, but it's a dual Pentium III (Coppermine) @ 800 MHZ each,
Linux w/ Sun's 1.3+:
Also, in terms of a UUID, are you talking about implementing a new native
call in the JVM or implementation thereof in order to obtain a MAC?
0ac097e1f9f0db55:2e000d:ee7ec50a0b:-8000:1024329058828
0ac097e1f9f0db55:2e000d:ee7ec50a0b:-7fff:1024329058829
0ac097e1f9f0db55:2e000d:ee7ec50a0b:-7ffe:1024329058829
0ac097e1f9f0db55:2e000d:ee7ec50a0b:-7ffd:1024329058829
0ac097e1f9f0db55:2e000d:ee7ec50a0b:-7ffc:1024329058829
0ac097e1f9f0db55:2e000d:ee7ec50a0b:-7ffb:1024329058830
0ac097e1f9f0db55:2e000d:ee7ec50a0b:-7ffa:1024329058830
0ac097e1f9f0db55:2e000d:ee7ec50a0b:-7ff9:1024329058830
0ac097e1f9f0db55:2e000d:ee7ec50a0b:-7ff8:1024329058830
0ac097e1f9f0db55:2e000d:ee7ec50a0b:-7ff7:1024329058830
--
J. S. Jensen, Cu.H.
Mark Thornton
"J. S. Jensen" <sp...@spam.com> wrote in message
news:3d0e...@news.mhogaming.com...
> In comp.lang.java.programmer Mark Thornton <m.p.th...@ntlworld.com>
wrote:
>
> > What is the system clock resolution on your Unix boxes?
>
> I just tested my Linux server box, and I can't get any delta on repeated
> System.currentTimeMillis() less than 10ms. I'll try on the Sun systems
> later today.
>
> > Given the time taken to obtain a VMID (~62ms @ 1GHz), a single 2.5GHz P4
>
> You mean through a new VMID().toString()?
important as some of the state is set up at that time. Conceivably you could
load but not initialise the classes.
> Also, in terms of a UUID, are you talking about implementing a new native
> call in the JVM or implementation thereof in order to obtain a MAC?
It would require a new native call through to the underlying OS provided
implementation. If you were to write your own implementation on top of a
method to obtain the MAC address then there is a risk of collisions with
UUIDs allocated outside of Java using the system UUID generator which would
be based on the same MAC address. So the JVM should only implement a UUID
generator when the OS does not provide one.
Mark Thornton
J. S. Jensen
> "J. S. Jensen" <sp...@spam.com> wrote in message
>> System.currentTimeMillis() less than 10ms. I'll try on the Sun systems
>> later today.
10ms the same.
> The 62ms only applies the first time (which includes class loading). This is
> important as some of the state is set up at that time. Conceivably you could
> load but not initialise the classes.
True:
<code>
System.out.println(System.currentTimeMillis());
Class.forName("java.rmi.dgc.VMID");
System.out.println(System.currentTimeMillis());
System.out.println(new java.rmi.dgc.VMID().toString());
System.out.println(System.currentTimeMillis());
</code>
SunOS (1.3):
1024339824875
1024339824894
192.168.2.22:19fb4d2:ee7f695100:-8000
1024339824898
Linux (1.3):
1024340089106
1024340089121
0ac097e1f9f0db55:30f13d:ee7f6d5921:-8000
1024340089122
I'm looking at about 19ms on SunOS and 15ms Linux, wonder if that's why.
> It would require a new native call through to the underlying OS provided
> implementation.
It would. Java on Unices is invoked via a shell script, thus I could manually
add a system defintion like -Dos.mac=<MAC> on JVM start.
:-)
--
J. S. Jensen, Cu.H.