[MUD-Dev] request for comments (was: Mud-Dev FAQ)

[JC Lawrence]

On Mon, 5 Jan 1998 09:10:52 PST8PDT 
Vadim Tkachenko<vadimt at 4cs.com> wrote:
> Jon A. Lambert wrote:

>> Variations on event-driven design

> Can you please elaborate on that?

There are a couple base models going about the list.  Jon and I have
some of the more intricate designs.  I'll let Jon describe his.

To describe my system loosely, and briefly:

  The server is heavily multi-threaded (I think the idle-state is over
50 threads currently).

  All events are processed aynchoinously and in parallel.  

  The server is lockless.

  I don't guarantee order of execution of two unrelated events.

  The base design:

    Events are logged with the Dispatchor in the Event List as a tuple
of an object:method call, various arguments, various ownership data,
and either a state time the event is to start execution, or a
percentage chance value that the event will start execution within any
given minute.

  The Dispatchor procresss the Event List, sending ripe events to the
Executor.

  The Executor receives the ripe events from the Dispatchor and stores
them in priority order in teh Event Queue.

  The Excutor processes the events in priority order by handing them
for processing to to the Event Pool, a dynamically sized pool of
threads.

  Events that fail to commit are rescheduled with the Executor at a
different priority.

  Event's have no effect upon the DB or state until and unless they
commit.

More details available on request.

>> Design of Object IDs and Object ID recycling

> ???

Many servers assign some form of unique ObjectID to their objects.
Typically this is done with a long integer or similar.  The problem
enters when that long integer overflows due to ongoing object
creation and destruction.  If old ObjectID's are recycled (ie an old
ObjectID # from a now deleted object is re-used) there is a potential
that an othe existant object may have stored a reference to that
object and may not attmept to reference the new object with the old
ObjectID, expecting it to still be the old object.

Thus the question of the design of ObjectID's and ObjectID recycling.

>> Virtual rooms, virtual objects, virtual mobiles

> ???

Think of them as second class objects, or temporary virtual objects
(ala lambdas or frobs).  Several server designs allow for objects to
be dynamically simulated without ever creating the objects themselves.

--
J C Lawrence                               Internet: claw at null.net
                                           Internet: coder at ibm.net
----------(*)                        Internet: jc.lawrence at sun.com
...Honourary Member of Clan McFud -- Teamer's Avenging Monolith...