[timfox]

Looking a the code I can seem a few potential issues:

1) The return value of getHardwareAddress() is assumed to be four bytes - I don't think that is a correct assumption.

Mac addresses are at least 48 bits. http://en.wikipedia.org/wiki/MAC_address
Also it's not guaranteed that a MAC address will be returned - it could be some other kind of addressing scheme.

2) The return value of InetAddress.getAddress() is also assumed to be four bytes. This will not be true for ipv6. No ipv6 check is done.

IPv6 addresses are 128 bits, IPv4 addresses are 32 bits. http://en.wikipedia.org/wiki/IPv6

We need an IPV4 address.

Looks like the code needs some more checking to be added.

[timfox]

"jmesnil" wrote:
in UUIDGenerator.generateTimeBasedUUID, we use only the 1st 4 bytes of the address so that it works with IPv4 (4 bytes), IPv4 (16 bytes) and MAC (6 bytes).

I don't think that will work. If you truncate the address we'll lose uniqueness.

It needs to be a ipv4 address or nothing, since that is the only thing that fits in 4 bytes.

MAC and IPv6 address is useless for this algorithm since they are too big.

If we can't get an ipv4 address we should just use a random.

[jmesnil]

the UUID requires 6 bytes for its spatially unique identifier node.
an IPv4 address is not enough and a MAC address will do.

If we want to provide a standard UUID, we need to use the MAC address when available (i.e. only on Java 6) and a random 6-bytes array otherwise.
On Java 5, we can also use an IPv4 address + 2 random bytes as the node identifier.

[timfox]

Can you join us on IRC?

[jmesnil]

after talking to tim on IRC, I've fixed and simplified the UUID generation making it compliant with the IETF draft (i.e. using 6 bytes to identify the spatial node) in r5804: http://fisheye.jboss.com/changelog/Messaging/?cs=5804

Clebert, this should fix the issue you had on Windows. Out of curiosity, could you still run the code snipped from my previous post on Windows?

[clebert.suconic]

Here you go:

Software Loopback Interface 1:byte[0]
WAN Miniport (L2TP):null
WAN Miniport (PPTP):null
WAN Miniport (PPPOE):null
WAN Miniport (IPv6):null
WAN Miniport (IP):null
RAS Async Adapter:null
WAN Miniport (SSTP):null
WAN Miniport (Network Monitor):null
Teredo Tunneling Pseudo-Interface:2:0:54:55:4e:1
Realtek RTL8139C+ Fast Ethernet NIC:ffffffde:ffffffad:ffffffbe:ffffffef:22:116
isatap.austin.rr.com:0:0:0:0:0:0:0:-32
WAN Miniport (IPv6)-QoS Packet Scheduler-0000:null
WAN Miniport (IP)-QoS Packet Scheduler-0000:null
WAN Miniport (Network Monitor)-QoS Packet Scheduler-0000:null

[jesper.pedersen]

Could you do something with the following warnings ?

 [javac] trunk/src/main/org/jboss/messaging/util/UUIDGenerator.java:132: warning: non-varargs call of varargs method with inexact argument type for last parameter;
 [javac] cast to java.lang.Class for a varargs call
 [javac] cast to java.lang.Class[] for a non-varargs call and to suppress this warning
 [javac] getHardwareAddressMethod = NetworkInterface.class.getMethod("getHardwareAddress", null);
 [javac] ^
 [javac] trunk/src/main/org/jboss/messaging/util/UUIDGenerator.java:146: warning: non-varargs call of varargs method with inexact argument type for last parameter;
 [javac] cast to java.lang.Object for a varargs call
 [javac] cast to java.lang.Object[] for a non-varargs call and to suppress this warning
 [javac] Object res = getHardwareAddressMethod.invoke(networkInterface, null);
 [javac] ^
 [javac] Note: Some input files use unchecked or unsafe operations.
 [javac] Note: Recompile with -Xlint:unchecked for details.
 [javac] 2 warnings

[clebert.suconic]

Do we need the , null on the method?


I removed it and on it compiled ok, without the warning. (at least on Java6... don't know about other JDKs as I don't have any other JDKs ATM)

[jmesnil]

Do we need the , null on the method?

silly me: the parameter is a varargs and is optional.
I'll remove the null parameters and the warnings will go away

[clebert.suconic]

Jeff,


I just did a test on my Windows, and this is the interface being used:

Address = Teredo Tunneling Pseudo-Interface 62:0:54:55:4e:1


And I'm not 100% sure this will be unique. It looks some Window$ weirdeness. (We would need someone to confirm that for us)

I was wondering, if we shouldn' t ignore dummy interfaces like that, or maybe sum all the Network interface' s addresses? Don' t know if that' s a silly idea.

[clebert.suconic]

If anyone out there with windows, wants to help us verifying this:

:-)

You just need to download trunk on SVN, build it and run org.jboss.messaging.tests.unit.util.UUIDTest through Eclipse

But before that add a System.out on UUIDGenerator::getHardwareAddress

 public final static byte[] getHardwareAddress()
 {
 Method getHardwareAddressMethod;
 try
 {
 getHardwareAddressMethod = NetworkInterface.class.getMethod("getHardwareAddress");
 }
 catch (Throwable t)
 {
 // not on Java 6 or not enough security permission
 return null;
 }

 try
 {
 Enumeration<NetworkInterface> networkInterfaces = NetworkInterface.getNetworkInterfaces();
 while (networkInterfaces.hasMoreElements())
 {
 NetworkInterface networkInterface = (NetworkInterface)networkInterfaces.nextElement();
 Object res = getHardwareAddressMethod.invoke(networkInterface);
 if (res != null && res instanceof byte[])
 {
 byte[] address = (byte[])res;
 byte[] paddedAddress = getZeroPaddedSixBytes(address);
 if (paddedAddress != null)
 {
 System.out.println(networkInterface.getDisplayName() + " " + asString(paddedAddress));
 if (log.isDebugEnabled())
 {
 log.debug("using hardware address " + asString(paddedAddress));
 }
 return paddedAddress;
 }
 }
 }
 }
 catch (Throwable t)
 {
 }

 return null;
 }

[clebert.suconic]

This fake adapter will have the same MAC on every Windows installed out there:

Just found a post on Technet, with the same MAC listed. So it is definetely not unique.


As Jeff said, we will need to blacklist that MAC:


http://social.technet.microsoft.com/Forums/en-US/winserverClustering/thread/2c83bdda-7cd4-4ee3-abeb-82b62199f3e1/


MAC Addresses were supposed to be unique.. right? So.. why M$ did it this way?

But oh well.. that's an issue for sure.