Greetings. :)

Shawn Halpenny rsh at dos.nortel.com
Wed Apr 9 10:08:50 New Zealand Standard Time 1997


On Apr 8,  8:47pm, Jeff Kesselman wrote:
> Subject: Re: Greetings. :)
> At 01:44 PM 4/8/97 -0400, you wrote:
> >On Apr 6,  8:23am, coder at ibm.net wrote:
> >
> >[ stuff about JCL's DB snipped ]
> >
> >> This is probably better understood from the inside oot, rather than trying
> >> to look at the server side:
> >>
> >>   Everything is an object.
> >>   Objects are defined in a database.
> >>   Objects have Unique IDs.
> >
> >I've been kicking this unique ID/object around as well, and was
> >wondering about how you generate them?  I haven't been able to find
> >any algorithms that would generate a unique ID given an object (or a
> >request to do so) without having to search the list of ID's already
> >generated.  I don't know for sure if that last bit is possible, but I
> >want things to still be speedy when the number of objects is large
> >(2^31).  I had an idea to keep track of the next available ID, and
> >each time an object was created, assign it that value, then bump the
> >value.  Whenever an object is destroyed, keep track of the last 'n'
> >(where n is something fairly small and manageable like 100) now-free
> >IDs and if you wrap your next-ID counter, pull them out of the list of
> >freed IDs.  If the list runs empty, you have to search, though.
> >There's optimization to be done in that, but that's the gist.
> >
> >Any magical algorithms? :)
>
> Hmm.... cold does this integrally. I uspsect it just keeps an efficeintly
> searched list. How abotu this....
>
> A "highest allocetd" counter and a list of available (freed) numbers.
> Yo uuse the first on the free list unless the lsit is empty in which case
> you bump the "highest' number and use that?
>
> Just some thoughts.
>
> JK

Actually, on my drive home from work yesterday, I had somewhat of an
epiphany regarding the unique IDs (Cynbe had also pointed out a very
similar scheme to me this morning):

- I've got a system clock that will be churning out unique values from now
until sometime in January 2038, so when I create an object, I should be
able to just snag the current time (with a granularity of probably
microseconds) and use that as the object's ID.  I suppose it wouldn't hurt
to save the most-recent-ID so that if there is a burp with the system
clock, I can ensure that I can restart the ID generation again at a proper
place (i.e. any time after my last ID).

That almost seems too easy and I can't help but think I've missed
something...

--
Shawn Halpenny




More information about the MUD-Dev mailing list