Hey Lex, 

Thank you for your response.  I had considered IP Address, computer name,
NIC address and PID.  But when I thought more about it I thought they were
too public.  I then considered adding the startup time of the image but it
was only accurate within a second and I figured it is possible that two
images would be started in the same second and that information could be
leaked out, so it wasn't good enough.  I would feel very comfortable with a
UUID if that UUID could be protected by the VM since in order to retrieve
information from an image an attacker would have to find the UUID for an
image.  Duplication of the id does not make this any easier.

Thanks again!

Ron

> -----Original Message-----
> From: squeak-dev-bounces at lists.squeakfoundation.org [mailto:squeak-dev-
> bounces at lists.squeakfoundation.org] On Behalf Of Lex Spoon
> Sent: Wednesday, August 23, 2006 6:56 PM
> To: squeak-dev at lists.squeakfoundation.org
> Subject: Re: FW: Image Unique Identifier
> 
> "Ron Teitelbaum" <Ron at USMedRec.com> writes:
> > I need a unique image identifier.  Does anyone have any suggestions?
> >
> > The identifier must be unique so that if someone copies an image to
> another
> > machine I get a new id.  It must also be unique by instance, so that if
> two
> > images or the same image is launched multiple times I should get unique
> > identifiers.   The id should be local and non transferable plus it
> should
> > never persist, since I would like to use this id to prevent movement
> between
> > images of objects like in spoon, magma, glorp, squeakELib, croquet, or
> any
> > other distributed objects scheme.
> 
> 
> UUID's are a sort of perpetual motion machine for computer science.
> They are nice to have, but none of them work, despite the large number
> of designs that are tantalizingly close.  It is better to talk about
> plain old identifiers, ID's.  They are never universally unique, so
> the first U should go; they are always *somewhat* unique, and so the
> second U is redundent.  It's just about identifiers.
> 
> The "universally" part seems possible for some people, so let me dwell
> on it a minute.  One problem is, if you have no restrictions on the
> execution environment, then you can have no grounds for ensuring
> uniqueness, either.  Anything that you might be using for uniqueness,
> might get duplicated if people are running your code on a virtual
> machine such as VMWare.
> 
> To address just one example, consider using a random number generator
> from the network.  First, you can never really know that two images
> are really calling the same generator server.  The Internet is a
> mysterious thing when you factor in firewalls, caches, and emulation.
> Further, if you somehow do know you are calling the same server, why
> not save yourself the headaches and have the server hand out plain old
> sequential ID numbers?
> 
> 
> Okay, enough bashing of UUID's.  For your problem, here are two
> possible avenues for (non-universally unique) ID's to use.
> 
> 1. An IP plus a process ID (which might be an IP port number) plus an
> image-wide unique number.  Such an ID is unique relative to a
> particular IP network, but of course can be duplicated--just think
> about all the computers in the world with address 192.168.1.1.
> 
> 2. You might want to use something like http URL's, with a hostname
> and a list of strings as the identifier.
> 
> 
> These are just ideas, though.  In the end, you need to spend some time
> thinking about the more specific problem.  Internet email's
> Message-ID's are a farce, but POP's UIDL's are simple and work.  The
> difference is that Message-ID's pretended to be universally unique,
> while UIDL's are only unique relative to a particular mail server.
> 
> -Lex
> 
> 
>