bdw+@cs.cmu.edu (Blake Ward) (06/03/91)
I have an application that runs on multiple macintoshes in a networked environment and I would like to be able to generate id numbers or strings that are guaranteed to be unique across the whole network. One way of doing this is to combine the machine's node id (selected by AppleTalk at startup and unique within the local network), its network number (again provided by AppleTalk), and the current time. Normally, this should produce a unique ID#. However, the machine's node id is selected at startup and a different machine could get the same node id after that machine is turned off. If the clock on the new machine is set to an incorrect time (earlier than the clock on the other machine), it's possible that the same ID# could be generated again. I realize that the chances of a duplicate ID# being generated are incredibly slim (and I'll probably have to live with this approach), but I was just wondering if anyone had come up with a clever scheme for generating ID#'s that are absolutely guaranteed to be unique. On a similar note, has anyone come up with a clever way to deal with the inevitable differences between the clocks on multiple Macintoshes sharing data (that includes timestamps) over a network. For instance, if one machine creates a piece of data, sets its creation time to the current time (say 8:35am), and then shares it with another machine on the network whose clock is currently reading 8:20am, the user of that machine will be very confused by this new piece of data with a creation date in the future. Simple inconveniences like this can be accounted for by comparing the clocks on the two machines and adjusting the value shown to the user, but things get much more complex when you start to consider things like using times to decide which version of a piece of data is the most current, especially when the network or individual machines might be going up and down, and clocks could be off by hours or days. I suspect that in general this is an intractable problem on an AppleTalk network, but any suggestions or clever solutions would be appreciated.