djones@megatest.UUCP (Dave Jones) (09/09/88)
What's the best way for a process to generate a network-wide unique number which will remain unique over time? (A very, very high probability of uniqueness may have to be good enough.) Just off the top of my head, I think of this idea: Add together the number that you get from gettimeofday(), and the number you get from getpid(), and a number you get by hashing the string obtained from gethostname(). Maybe you want to multiply the getpid number by 100000 or so before you add it. I thought of using the ethernet machine address, which admittedly adds a little bit more non-portability, but I don't know exactly how to look it up at runtime anyway. Anybody got an idea on this? Sun gurus: Can the yellow-pages daemon or the portmapper be any help?
mishkin@apollo.COM (Nathaniel Mishkin) (09/09/88)
In article <775@goofy.megatest.UUCP> djones@megatest.UUCP (Dave Jones) writes: >What's the best way for a process to generate a network-wide >unique number which will remain unique over time? (A very, very >high probability of uniqueness may have to be good enough.) As part of Apollo Network Computing System (NCS), we addressed this very issue. The Apollo OS has long used unique identifiers (UIDs). UIDs prove to be very useful in a distributed environment. They can be generated in a distributed fashion (no appeal to a central authority required) and they always mean the same thing (you never have to check to make sure that identifier that you got at some earlier time still refers to what you think it refers to). The Apollo OS UIDs are 64 bits long and consist of a 36 bit time value (16ms units) and a 20 bit "node number" (all Apollo workstations have such a number in hardware) and some other (currently unused bits). The software ensures that even if you try to generate UIDs "too fast", you still get unique ones (it keeps enough "spares"). Anyway, when we did NCS we realized we'd have to generalize this scheme somewhat, so we invented what we call "Universal UIDS" (UUIDS). UUIDs are 128 bits longs and consists of a 48 bit time value (4us units) and a 64 bit location (and again some unused bits). The location is represented roughly like Berkeley "struct sockaddr" (minus the "port") -- there's a 8 bit "address family" and 7 bytes (zero padded) of network address. A host can pick whatever it wants as the location, as long as it's unique. (E.g. it can use PF_INET and its IP address or it could use PF_NS and its ethernet address.) People occasionally tell me things like how ISO addresses can be 1024 bits long and all I can do is shrug and sigh for now. (I think UUID generation will be the least of the problems a system with 1024 bit network address will have.) On Unix systems NCS's default UUID generator uses IP-type UUIDs and to make sure that it's generating unique time values, stores the last UUID generated in a file (that is accessed under flock/lockf calls). Not terribly fast, but you don't generate UUIDs all that often and better right than fast. (Systems that have decent shared memory support could probably do a better job.) With a little effort, I can probably extract the UUID generation stuff from the NCS source code and make it generally available. It's not all that complicated, although if you want almost anything to work on various flavors of Unix, MS/DOS, and VMS (as we do), almost nothing is easy. NCS uses UUIDs to indentify network interfaces, objects, object types, and "activities" (processes making remote calls). -- -- Nat Mishkin Apollo Computer Inc., Chelmsford, MA mishkin@apollo.com
gandalf@csli.STANFORD.EDU (Juergen Wagner) (09/10/88)
Since the hostid is unique, and since there shouldn't be an upper limit to
those numbers, just use
counter * 2^32 + hostid
(counter is incremented every time a new id is requested). That way, you have
a number which is unique in the network, and you can keep the counters local,
so you don't need overhead for net traffic.
Masking out the lower 32 bits will even tell you where the client got its id
from.
--
Juergen "Gandalf" Wagner, gandalf@csli.stanford.edu
Center for the Study of Language and Information (CSLI), Stanford CAaad@stpstn.UUCP (Anthony A. Datri) (09/14/88)
In article <5412@csli.STANFORD.EDU> gandalf@csli.stanford.edu (Juergen Wagner) writes: >Since the hostid is unique, and since there shouldn't be an upper limit to >those numbers, just use Don't all MicrovaxII's have the same hostid? -- @disclaimer(Any concepts or opinions above are entirely mine, not those of my employer, my GIGI, or my 11/34) beak is beak is not Anthony A. Datri,SysAdmin,StepstoneCorporation,stpstn!aad
mike@turing.unm.edu (Michael I. Bushnell) (09/15/88)
In article <2093@stpstn.UUCP> aad@stpstn.UUCP (Anthony A. Datri) writes: >In article <5412@csli.STANFORD.EDU> gandalf@csli.stanford.edu (Juergen Wagner) writes: >>Since the hostid is unique, and since there shouldn't be an upper limit to >>those numbers, just use > >Don't all MicrovaxII's have the same hostid? Huh???? Not a chance. They all have SIMILAR system ID registers, but that is a very different thing. The hostid is a variable maintained by the kernel, very analogous to the hostname. It is set by sethostid and read by gethostid. You get 32 bits of data. It is intended that this be the "canonical" Internet address for the machine. Gateways should choose their most "external" address. -- N u m q u a m G l o r i a D e o \ Michael I. Bushnell \ HASA - "A" division /\ mike@turing.unm.edu / \ {ucbvax,gatech}!unmvax!turing.unm.edu!mike