From: markkj@mullian.ee.mu.OZ.AU (Mark Johnston)
Subject: Re: DISTRIBUTED MUDDING
Organization: Computer Science, University of Melbourne, Australia
Date: Tue, 15 Dec 1992 22:21:18 GMT


	I was interested to read all of these articles talking about having
actual rooms distributed across the different mud servers, as I have started
working on a multi-processing mud (by this I mean that the mud is run on a
machine with >1 processor) with a friend.  We decided to start from scratch
with this, as modifying the LP code could be a nightmare...  The design
is to have a separate compiler, which produces some "m-code" (just some
plain old byte code), and this code is executed on one of several virtual
machines (VM's for short).  The threads of execution can move between VMs,
to make sure that the maximum throughput is obtained.  One of the other
reasons we decided to write a mud was to add a tile-based map system to the
game.  Objects are to have a number representing a 'sprite' number, and
all objects that can contain other objects have a 'map'.  The map represents
the layout of a room, and on top of this, the object sprites are drawn.  This
requires that all move_object() calls send updates to all interactive objects
that are in/near/containing the moved object.  This in itself would slow down
the rate at which the threads of execution are executed.

    To coordinate the variable-locking on a system like this is not easy to do,
as two processes writing into a shared memory segment can do this at the same 
time.  Using shared semaphores is a way of getting around this problem, but as
one could imagine - it gets _very_ messy.  The solution that we've come up with
is using a single driver to do all of the task-allocation (Tasks are threads of
execution within the objects, but they are not bound to the object that they
started in...) over all of the virtual machines that interpret the byte code.

    Expanding this idea to a mud that works across different machines, rather
that just processes on one machine would have some benefits and a number of
disadvantages.  The disadvantages inculde the lack of a distributed 
shared-memory system (the m-code is stored in a shared memory arena, so that
the VMs don't have to send requests to the driver to get hold of the code that
they're supposed to be executing...) which would mean that the m-code would
either have to be passed to the different drivers by NFS or through sockets.
(I know how much the systems people at most universities would appreciate
setting up NFS links to places halfway around the world... :-)

    A distributed version of our mud would work well for local groups of
machines, but for international groups... it could be a bit slow.  This
way, all rooms could respond to commands at approximately the same rate
(on average).  Link speeds may not be such a problem for those in the US,
but for people down here, machines overseas have reponse rates of 600ms
(ie the west-coast of the US) up to about 3000ms for machines in france & the
UK.  What I am basically saying (if the above is not clear - which it probably
isn't :-) is "Why link location in the mud to location on the internet?".


        Mark. (aka Farlinnin)


================================================================================
                                              | markkj@marvin.its.unimelb.edu.au
Real programmers get it right the first time: | markkj@munagin.ee.mu.oz.au
                                              | markkj@krang.vis.citri.edu.au
    #include "/dev/tty"                       | markkj@mundil.cs.mu.oz.au
                                              |    mkj@tauon.ph.unimelb.edu.au
================================================================================

Newsgroups: rec.games.mud.lp