Smalltalk
› Squeak
› Croquet
›
Croquet - Dev
machine-specific unique identifiers?
Locked
machine-specific unique identifiers?
 
|
What's the right way to get unique identifiers that are different
from machine to machine? TObject new - gives a repeatable pattern when executed on an island. This is by design, to keep islands in synch. (By the way, the above is deprecated. Using the latest packages in the repository, one uses TObject for: somethingToUseAsALabel.) But suppose you want an identifier to use, for example, to designate the Web cam or microphone on my particular machine? In our code, we do this lazily, when required. So it might happen on an island or off. The way we have been doing it is: TCryptoRandom default nextInto: TObjectID nilObjectID But this isn't quite right either. It turns out that TCryptoRandom default isn't seeded with any entropy, so it gives the same reproducible results on each machine when executed off island (i.e., in the "ocean", e.g., in harness code). So for now, we're seeding TCryptoRandom default at startup time. Is this a misuse of TCryptoRandom default? It seems like it is intended to give secure randoms, which I would think should be different on different machines and not a reproducible series on each Squeak restart. So it seems like a bug, but maybe I'm mis-interpreting? Another approach, hinted at in http://bugs.impara.de/view.php?id=2588, is to define a TUniqueID which would have a properly seeded generator in a class var. Is that better than the above code (with the seeeding fix)? Why or why not? |
Re: machine-specific unique identifiers?
|
|
Howard Stearns wrote:
> What's the right way to get unique identifiers that are different > from machine to machine? Ask your local island for a TObjectID. > TObject new - gives a repeatable pattern when executed on an island. > This is by design, to keep islands in synch. Right, but only for replicated islands. Non-replicated islands (like your local island) get specifically seeded such that they create unique TObjectIDs (if this were different we'd have a BIG problem with naming the results of future sends from any local machine). > But suppose you want an identifier to use, for example, to designate > the Web cam or microphone on my particular machine? > In our code, we do this lazily, when required. So it might happen on > an island or off. The way we have been doing it is: > TCryptoRandom default nextInto: TObjectID nilObjectID > But this isn't quite right either. It turns out that TCryptoRandom > default isn't seeded with any entropy, so it gives the same > reproducible results on each machine when executed off island (i.e., > in the "ocean", e.g., in harness code). So for now, we're seeding > TCryptoRandom default at startup time. Oops. TCryptoRandom>>default is a left-over from historic days. You should use the island's RNG (and TCryptoRandom>>default should delegate to that RNG) which is seeded in CroquetHarness>>initialize. > Is this a misuse of TCryptoRandom default? It seems like it is > intended to give secure randoms, which I would think should be > different on different machines and not a reproducible series on each > Squeak restart. So it seems like a bug, but maybe I'm mis-interpreting? It is a bug in such that the class var Default shouldn't exist at all. If a default is to be used it needs to be the RNG from the current island. > Another approach, hinted at in > http://bugs.impara.de/view.php?id=2588, > is to define a TUniqueID which would have a properly seeded > generator in a class var. Is that better than the above code (with > the seeeding fix)? Why or why not? This whole idea of TUniqueID is a red herring. When I wrote this bug report I didn't quite understand what is going on. It's all in seeding your local island properly. Cheers, - Andreas |
Re: machine-specific unique identifiers?
|
|
In reply to this post by Howard Stearns
Why use a TObjectID, when you could as easily generate a UUID
(primitiveMakeUUID)? Does TObjectID use the UUID facility? -Kyle H On 7/10/06, Andreas Raab <[hidden email]> wrote: > Howard Stearns wrote: > > What's the right way to get unique identifiers that are different > > from machine to machine? > > Ask your local island for a TObjectID. > > > TObject new - gives a repeatable pattern when executed on an island. > > This is by design, to keep islands in synch. > > Right, but only for replicated islands. Non-replicated islands (like > your local island) get specifically seeded such that they create unique > TObjectIDs (if this were different we'd have a BIG problem with naming > the results of future sends from any local machine). > > > But suppose you want an identifier to use, for example, to designate > > the Web cam or microphone on my particular machine? > > In our code, we do this lazily, when required. So it might happen on > > an island or off. The way we have been doing it is: > > TCryptoRandom default nextInto: TObjectID nilObjectID > > But this isn't quite right either. It turns out that TCryptoRandom > > default isn't seeded with any entropy, so it gives the same > > reproducible results on each machine when executed off island (i.e., > > in the "ocean", e.g., in harness code). So for now, we're seeding > > TCryptoRandom default at startup time. > > Oops. TCryptoRandom>>default is a left-over from historic days. You > should use the island's RNG (and TCryptoRandom>>default should delegate > to that RNG) which is seeded in CroquetHarness>>initialize. > > > Is this a misuse of TCryptoRandom default? It seems like it is > > intended to give secure randoms, which I would think should be > > different on different machines and not a reproducible series on each > > Squeak restart. So it seems like a bug, but maybe I'm mis-interpreting? > > It is a bug in such that the class var Default shouldn't exist at all. > If a default is to be used it needs to be the RNG from the current island. > > > Another approach, hinted at in > > http://bugs.impara.de/view.php?id=2588, > > is to define a TUniqueID which would have a properly seeded > > generator in a class var. Is that better than the above code (with > > the seeeding fix)? Why or why not? > > This whole idea of TUniqueID is a red herring. When I wrote this bug > report I didn't quite understand what is going on. It's all in seeding > your local island properly. > > Cheers, > - Andreas > > > |
Re: machine-specific unique identifiers?
|
|
In reply to this post by Howard Stearns
TObjectID does not use the UUID primitive because we want to be able to
compute replicated object IDs just as well as non-replicated (truly unique) ones. UUIDs can only be used for the latter and in most situations it is not known whether using a UUID is acceptable (e.g., whether the current computation may be replicated or not). Therefore, all of the Croquet code uses TObjectID which can be used for both purposes. Cheers, - Andreas Kyle Hamilton wrote: > Why use a TObjectID, when you could as easily generate a UUID > (primitiveMakeUUID)? Does TObjectID use the UUID facility? > > -Kyle H > > On 7/10/06, Andreas Raab <[hidden email]> wrote: >> Howard Stearns wrote: >> > What's the right way to get unique identifiers that are different >> > from machine to machine? >> >> Ask your local island for a TObjectID. >> >> > TObject new - gives a repeatable pattern when executed on an island. >> > This is by design, to keep islands in synch. >> >> Right, but only for replicated islands. Non-replicated islands (like >> your local island) get specifically seeded such that they create unique >> TObjectIDs (if this were different we'd have a BIG problem with naming >> the results of future sends from any local machine). >> >> > But suppose you want an identifier to use, for example, to designate >> > the Web cam or microphone on my particular machine? >> > In our code, we do this lazily, when required. So it might happen on >> > an island or off. The way we have been doing it is: >> > TCryptoRandom default nextInto: TObjectID nilObjectID >> > But this isn't quite right either. It turns out that TCryptoRandom >> > default isn't seeded with any entropy, so it gives the same >> > reproducible results on each machine when executed off island (i.e., >> > in the "ocean", e.g., in harness code). So for now, we're seeding >> > TCryptoRandom default at startup time. >> >> Oops. TCryptoRandom>>default is a left-over from historic days. You >> should use the island's RNG (and TCryptoRandom>>default should delegate >> to that RNG) which is seeded in CroquetHarness>>initialize. >> >> > Is this a misuse of TCryptoRandom default? It seems like it is >> > intended to give secure randoms, which I would think should be >> > different on different machines and not a reproducible series on each >> > Squeak restart. So it seems like a bug, but maybe I'm >> mis-interpreting? >> >> It is a bug in such that the class var Default shouldn't exist at all. >> If a default is to be used it needs to be the RNG from the current >> island. >> >> > Another approach, hinted at in >> > http://bugs.impara.de/view.php?id=2588, >> > is to define a TUniqueID which would have a properly seeded >> > generator in a class var. Is that better than the above code (with >> > the seeeding fix)? Why or why not? >> >> This whole idea of TUniqueID is a red herring. When I wrote this bug >> report I didn't quite understand what is going on. It's all in seeding >> your local island properly. >> >> Cheers, >> - Andreas >> >> >> > > |
Re: machine-specific unique identifiers?
|
|
In reply to this post by Howard Stearns
Excellent. Thanks, Andreas.
By "local island", do you mean the harness systemIsland, or the Smalltalk island (aka the ocean), or something else? - The Smalltalk island, I think, produces the same sequence of TObjectID after each startup. (Smalltalk island exists, so Island>>initialize isn't run for each machine on startup.) - The harness systemIsland is going to be a far ref from the ocean. [harness systemIsland future new: TObjectID] will give me another far ref. Is there a better way to be getting a machine-specific unique TObject in the ocean? By the way, there's "stuff" in the harness systemIsland as built by CroquetHarness>>setupLocal. Does anything use that? Can I trash it? On Jul 10, 2006, at 1:32 PM, Andreas Raab wrote: > Howard Stearns wrote: >> What's the right way to get unique identifiers that are different >> from machine to machine? > > Ask your local island for a TObjectID. > >> TObject new - gives a repeatable pattern when executed on an island. >> This is by design, to keep islands in synch. > > Right, but only for replicated islands. Non-replicated islands > (like your local island) get specifically seeded such that they > create unique TObjectIDs (if this were different we'd have a BIG > problem with naming the results of future sends from any local > machine). > >> But suppose you want an identifier to use, for example, to designate >> the Web cam or microphone on my particular machine? >> In our code, we do this lazily, when required. So it might happen on >> an island or off. The way we have been doing it is: >> TCryptoRandom default nextInto: TObjectID nilObjectID >> But this isn't quite right either. It turns out that TCryptoRandom >> default isn't seeded with any entropy, so it gives the same >> reproducible results on each machine when executed off island (i.e., >> in the "ocean", e.g., in harness code). So for now, we're seeding >> TCryptoRandom default at startup time. > > Oops. TCryptoRandom>>default is a left-over from historic days. You > should use the island's RNG (and TCryptoRandom>>default should > delegate to that RNG) which is seeded in CroquetHarness>>initialize. > >> Is this a misuse of TCryptoRandom default? It seems like it is >> intended to give secure randoms, which I would think should be >> different on different machines and not a reproducible series on each >> Squeak restart. So it seems like a bug, but maybe I'm mis- >> interpreting? > > It is a bug in such that the class var Default shouldn't exist at > all. If a default is to be used it needs to be the RNG from the > current island. > >> Another approach, hinted at in >> http://bugs.impara.de/view.php?id=2588, >> is to define a TUniqueID which would have a properly seeded >> generator in a class var. Is that better than the above code (with >> the seeeding fix)? Why or why not? > > This whole idea of TUniqueID is a red herring. When I wrote this > bug report I didn't quite understand what is going on. It's all in > seeding your local island properly. > > Cheers, > - Andreas > |
Re: machine-specific unique identifiers?
|
|
In reply to this post by Howard Stearns
Howard Stearns wrote:
> By "local island", do you mean the harness systemIsland, or the > Smalltalk island (aka the ocean), or something else? I mean TIsland>>default. The harness' systemIsland is something that we're still not quite sure if we want to replicate it or not. > - The Smalltalk island, I think, produces the same sequence of TObjectID > after each startup. (Smalltalk island exists, so Island>>initialize > isn't run for each machine on startup.) Ah. Legacy reasons again. This initialization happens in CroquetHarness>>initialize because for the longest time we didn't have a good entropy source and I wanted to be able to catch this problem early on. This could go as well into TIsland>>startUp or so. For the time being, just do this (at any place you like): seed := ByteArray new: 128. TCryptoRandom gatherEntropy: seed. Island default randomStream seedVector: seed. Note that multiply seeding the random stream is not a problem since it's non-replicated. > - The harness systemIsland is going to be a far ref from the ocean. > [harness systemIsland future new: TObjectID] will give me another far > ref. Is there a better way to be getting a machine-specific unique > TObject in the ocean? This is incorrect. The reason being that you should NEVER ask another island for an object ID you want to use locally. It just doesn't make any sense. An object ID is (effectively) a name for some object and should always come from the local pool of names unless you are explicitly trying to refer to an object in another island in which case you should of course use a name from that island's pool. > By the way, there's "stuff" in the harness systemIsland as built by > CroquetHarness>>setupLocal. Does anything use that? Can I trash it? Don't know. If in doubt, try it ;-) Cheers, - Andreas |
«
Return to Croquet - Dev
|
1 view|%1 views
| Free forum by Nabble | Edit this page |