[MUD-Dev] Re: [DevMUD] Re: Database module

J C Lawrence claw at kanga.nu
Mon Dec 21 22:24:33 CET 1998


On Mon, 21 Dec 1998 23:22:33 -0800 (PST) 
cynbe <cynbe at muq.org> wrote:

> On 22-Dec-98 J C Lawrence wrote:

>> I went thru the problem of ObjectID's and their re-use on MUD-Dev
>> extensively.  A key problem is that there may be pointers or
>> references to an object after the object has been destructed, and
>> that once you have an ObjectID->human_readable->ObjectID
>> translation mapping, you can never guarantee that a reference count
>> is accurate.

> JLC's solutions, as always, are sensible and effective.

<kof>

> I've been using a slightly different wrinkles for similar problems:

> (1) Instead of using a time_t as guard bits, one can use a
> trulyRandom integer. 

Within very large values of "TRUE" there are no truly random number
generators.  Yes, there are some, just not many (ie I'd wager not from
from 1,000 on the planet, total).  (cf LavaRand at
http://lavarand.sgi.com/ -- I work with some of the guys that did
LavaRand BTW).

> It is often practical to make this long enough to make collision
> probability effectively zero for the purposes at hand.  

Unfrotunately approximately zero is never quite the same as zero.

> If you have to code trulyRandom integer generation up from scratch,
> this may not be worth the effort, but almost any distributed system
> these days will have true random bits implemented for public-key &tc
> purposes, so the incremental cost of using them is often very low.

Ahem.  Not quite true.  They may have damned good PRNG's, very well
tested, graphed, measured, and expertly coded PRNG's with well
documented behaviours and caveats, but they are very definitely
Pseudo-RNG's.

Why go for a PRN, especially when its a time bomb waiting to happen
that you can't predict, can't detect when it doesn happen, and can't
(usefully or elegantly) handle the effects of when it does blow up?
Yes, its bloody rare, I'm just not fond of that sort of thing,
especially when I have an alternative and a guaranteed correct one at
that (assuming system time is reliable (Kanga.Nu is NTP stratum 3
right now, soon to be stratum 2 if I have my way)).

> (2) If you need to pass numbers through human channels, a possible
> improvement on UUENCODE-ing style translation is: (a) Pick a set of
> 1024 words (probably short, single-syllable words) (b) bite off
> 10-bit chunks from your integer, and use each to select a word from
> the set: A 64-bit integer becomes seven words.  The result will be a
> number encoding with much more mnemonic value to native speakers
> than the corresponding UUENCODE-ed version: I'm sure any of us can
> remember seven words easier than 16 random hex digits.  (For extra
> credit: Pick separate verb, noun and adjective sets of 1024 words,
> and arrange for your numbers to make grammatical sentences.  I'll
> bet this will increase the mnemonicity of the encoded numbers
> significantly.)

Nice.

--
J C Lawrence                              Internet: claw at kanga.nu
----------(*)                            Internet: coder at kanga.nu
...Honorary Member of Clan McFud -- Teamer's Avenging Monolith...




More information about the mud-dev-archive mailing list