[Insight-developers] gdcmUtil.cxx polling for a MAC Address

[David Clunie]

kent williams wrote:

 > The workaround you're using means you're not generating a unique UID for
 > your DICOM files, and therefore aren't compliant with the DICOM spec. Not
 > that it should stop you -- no one else complies completely with the DICOM
 > spec, why should you?

This attitude makes trying to achieve a high level of interoperability and
compatibility harder.

Are you surprised when clinical IT staff reluctant to allow any images
produced by research software onto the clinical network ?

Rest assured that there are plenty of people who achieve 100% compliance
with the DICOM standard on a routine basis, as well as plenty of tools
to test the compliance of one's own output.

Mathieu Malaterre wrote:

 > As Kent says, it is not much of an issues. It will simply
 > exponentially increase the chance of your customer to produce
 > duplicate DICOM files throughout the world. the real issue lie in the
 > fact the the ITK root is used by potentially dozen of people at the
 > same time, so producing unique identifier (software implementation,
 > not hardware) is  a hard problem. To minimize the risk of collision I
 > used a machine identifier (MAC address), a time identifier (up to
 > millisecond) and in the couple of bytes remaining I stuffed in a
 > couple of random bytes.
 > So the questions are:
 >
 > 1. Are your customer going to produce DICOM files ?
 > 2. If 1) do they have there own root UID ?
 > 3. Do they plan to produce DICOM from two machines at the same time ?
 >
 > If 2) and not 3) then it is safe to remove the machine identifier as
 > collision cannot appear. In which case a simple #cmakedefine to
 > replace the MAC address by an empty string is valid.

It is never safe nor appropriate to generate UIDs that are not expected
to be globally unique.

Even if one were totally convinced that the generated DICOM image files
were never going to escape from the lab, even within a single lab, two
instances of the same code may generate a conflict sooner or later,
as you point out.

It is not as hard as it used to be to find sources of uniqueness on most
platforms these days, even in the absence of a network interface with
a MAC address.

Regardless, I think it is the toolkit implementer's responsibility to make
sure that this works and that the programmer using the toolkit is not
bothered by this issue, and is not able to produce "bad" DICOM files that
have dubious UIDs.

In my earlier toolkits I made obtaining a root the
responsibility of the user; nowadays I know better and just take care of
it internally in my more recent toolkits. For example in Java I use the
java.rmi.dgc.VMID and fall back to trying to find a MAC address instead
only if VMID.isUnique() is false. I recall looking once at the JRE source
code to find out where Sun is getting the VMID, though I don't remember
the details, but one could use the same approach if one needed to replicate
this in C++ in the absence of library support for this sort of thing.

The hardest part is finding a way to fit everything into 64 bytes. I also
use a counter nowadays, rather than just "a few random bytes", since I
found that if I asked for UIDs fast enough I could generate them faster
than millisecond precision making the timer insufficient for disambiguation;
the counter value took up fewer bytes than a sufficiently random number.

David