[MUD-Dev] Languages for MUD drivers

[J C Lawrence]

On Wed, 17 Nov 1999 22:13:44 +0100 
Laurent Bossavit <bossavit at cybercable.fr> wrote:

> There's no really good (read transparent) way to interconnect
> several MOO servers in that way. Suppose I'm running the Feral
> Forest on server A, the Damp Dungeon on server B; I want the key
> from the lower dungeon cell to open the witch's hut in the forest
> - hence I want the player to be able to take the key and move from
> A to B, moving the key with em - and there's no way AFAIK that can
> be done with MOO.

CoolMUD implements a simple object RPC protocol called "YO" which
can work for this, given that the interconnect between the servers
is both fast and of low latency:

--<cut>--
COOLMUD is distributed in a different way than other "distributed"
systems such as UnterMUD.  Instead of providing a method of sending
objects from database to database, COOLMUD allows you to define a
suite of messages which may be passed between objects.  The YO
protocol and the COOLMUD database define the suite of messages for a
particular implementation.

For example, symbolically, a typical exchange between objects might be:

        object A                    object B
        --------                    --------
        - what is your location?
                                    - my location is ...
        - move yourself to ...
                                    - ok

Objects don't actually move from machine to machine; they simply
update their location and contents fields to move around.  The
object remains on the server it was created on; its location
field simply 'points' to the object representing its new location. 
This means that anything which may be done with a local object can
be done with a remote object.  Thus, you may program a fancy object
on your local mud, carry it to a remote mud, and all the
functionality comes along with it.

There are two major limitations in COOLMUD:

1)  Inheritance may not span MUDs.  The parent of an object must
    reside on the same MUD as the child object.  This is done to
    reduce network traffic to an acceptable level, and to simplify
    the message passing system.

2)  To program an object, both the player and the object being
    programmed must reside on the same server.  This also reduces
    net traffic, since the COOL code only has go across one link
    (that between a player and the local MUD).
--<cut>--

and:

--<cut>--
The YO (Yell at Object) protocol defines the format and content of
messages that may be passed between severs on a distributed MUD.  It
does not ferry objects around, as the OIF protocol does, but instead
defines the messages that may be passed between objects.

COOLMUD users and programmers do not need to know the YO protocol
to program or use COOLMUD.  This document is intended for people
who want to know the internals of the COOLMUD system.

YO packets consist of 7 parts:  the message id, age, player object,
from object, to object, message, and arguments.  Any object can send
any other object a message, but it must be directed to the appropriate
server.  Any messages which do not conform to this format may be
silently discarded.

Here's a dissection of a typical YO packet:

3245    0   #3 at joemud  #7 at joemud  #9 at fredmud  "tell"  { 1 "howdy" }
  ^     ^       ^           ^          ^        ^           ^
  |     |       |           |          |        |           | 
msgid  age    player       from        to      msg         args
--<cut>--

You can find the relevent docs and source files in the CoolMUD
archives on ftp.kanga.nu, or at Stephen White's university site.

> Even assuming something like an 'object exchange protocol' that
> would let server A open a connection to server B, spit out the key
> object's code and properties so that a new, equivalent object can
> be created there, and the old key deleted; assuming I have a way
> to make sure the key won't be duplicated or deleted altogether if
> something happens to the network connection between A and B while
> this is going on; assuming I can do the same to the player object;
> assuming I can require the player emself to disconnect from A and
> reconnect to B in an orderly fashion whenever this happens - which
> implies a custom client program, or tech support headaches...

Object migration between hosts is not a trivial problem, but it is
also a problem that is well known and has significant prior art.
I'm being remarkably unsuccessful in finding that prior art right
now, but that could have something to do with the fact that I'm
quite hungry and not looking forward to the three block walk thru
the rain to a foodery.

The "OIP Porotocol" referenced above appears to refer to work done
by the OIP group in regard to Java/Corba translations:

  http://www.mcc.com/projects/oip/
  http://www.mcc.com/projects/oip/papers/paper067.htm

I don't see a whole lot of direct use (for us) there.

> Hmm, I can't assume all of the above anyway since it's far from
> realistic, but you see where this would lead - a lot of in-DB code
> that deals only with such interconnections. (And what if the key
> has a property pointing to another object local to A; and what if
> the key has parent objects that are not in B, etc. etc.) It's much
> better if such distributed processing is in some appropriate
> fashion a capability of the server itself. MOO as it is doesn't
> fit the bill; and adding these capabilities to a MOO server
> wouldn't be a piece of cake.

My assertions:

  -- persistance should be an innate and invisible (not just
transparent) property of the programming environment.  Translation;
Everything is persistant.  Always.

  -- distribution should be an innate and invisible property of the
programming environment.  Translation:  There is no innate
difference between a local object and a remote object other than
responsiveness.

  -- the user, be it programmer or player, should never need to be,
or be aware of how the system handles runtime object heirarchy
changes other than the mere fact that "it happens" and that they
don't need to care about it.  Translation: You just write or use
code and the system takes care of the rest and always does the right
thing.

  -- the user programmer shoul be able to behave and program as if
he were the only user on the system, that the system in fact was
solely dedicated to him and no other users or processes necessarily
existed, and he had compleat and total access to all resources
without adversely affecting the server's operation, performance, or
game-world operation.  Translations: race conditions, data locking,
deadlocks, etc are all non-existent terms within the programming or
user environment.

  -- inter-ibject security should be an understandable fact that can
be drawn and in less than 10 seconds on a restaurant napkin, not a
bolt-on mishmash of alter-cases some arbitrary interpretation of
which happens to be what the server might do (pet peeve).
Transaltion: Not ACL's.  Not Uber.  Not Tiny.  Not MOO.  Not LPC.  

  -- any feature must be programmable on any object without source
access to any other object(s).  This is actually one of the toughest
constraints of the above set.  Translation: You must be able to
rewrite an object's behaviour without changing the source for that
object.

I've been looking into Arjuna's and YOODA's distributed data
archictecture for the data handling side.  I'm not entirely fond of
either as they expose various aspects of the distribution model to
the user.

> In fact, my port to Java did include distributed operation
> support, based on RMI. One of the first things that became
> apparent as I was implementing it was that some MOO-language
> modifications would be necessary; the very least I could get away
> with was a syntactic representation of remote objects, i.e. the
> literal #1 referred to the local #1 whereas #my.server.com:1
> referred to #1 on my.server.com. With these modifications it was
> possible to call verbs and read or write properties on remote
> objects transparently, as if they were local.

Very Yo-like.

>> I'm not sure of what you are refering to when you say concurrent
>> processing support?  I understand the term, but I don't
>> understand the context re reactive worlds?

> I'm basically referring to support for preemptive (rather than
> MOO's collaborative) multitasking. Task scheduling seems to be a
> primary cause of lag in MOO servers - true multithreading means a
> server is more responsive; at least that's the theory.

You might like to hit the archvies to see Lambert's and rather
different approaches to this.  I use a lockless DB model with
competitive multi-threading built using rollbacks atop an ACID DB.
Lambert uses a variously intelligent look-ahead locking schema that
attempts to pre-emptively predict and route around lock conditions.

> This is a central feature, at least IMHO, of a modern M* server -
> because it lets you write in-DB editors. This may seem peripheral
> to some, but it's crucial to the notion of a virtual reality : the
> point of MUDs and MOOs was that they could be modified 'from the
> inside', which made them more like the real world - we don't 'step
> outside' the real world when we want to modify it, but modify it
> we do !

Well said sir.

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


_______________________________________________
MUD-Dev maillist  -  MUD-Dev at kanga.nu
http://www.kanga.nu/lists/listinfo/mud-dev