[MUD-Dev] Languages for MUD drivers

[Ian Macintosh]

    > Laurent Bossavit wrote:
    > Sent: Thursday, 18 November 1999 10:14
    >
    > Ian Macintosh sez:
    >
    > > Distributed processing support can be handled by
    > running multiple
    > > processes and interconnecting them.  I've always
    > thought that this is
    > > a better way of handling large systems and a large
    > number of users.
    > > ie, segment areas (zones) onto different servers and
    > link them.
    >
    > 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.
    >
    > 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...

I agree, this isn't trivial.  I've been working through these problems
myself as I get a distributed system up.  One of the first things I
realised is that a custom client program was an absolute *must*.  I
found that simpler than expected.  (see http://ncohafmuta.com/~iman/
where I have two clients.  They're alpha stuff, so don't expect too
much.  Also, the one is designed to be a chat system client, not a mud
client.  If you're trying to see the sound stuff in action, type
'multimedia' when logged in.  It's a toggle).

As far as handling the movement of objects (creating on second,
deleting on first), that is definately possible.  I can give you some
MOO code for that if you like, just don't ask for it like tomorrow.
I'll have to try and dig stuff up from two years ago.  I remember
there was a MOO system somewhere that had this capability.  I can't
remember who wrote it exactly, but I think it was somebody called
himself 'Kip the Kid', or 'King of Pascal' ??

When I tried it out, I decided that the only way was to open new
listening objects on each server, and to use the OOB communications
capability (#$# prefix by default).  Also, I never actually deleted an
object, I just flagged it as 'ownership transferred to <SERVER_ID>
with OBJ #'.  I then wrote a verb called 'check-database
check-database-nasty' which scanned for lost ownership items and
reinstated them on the primary server.  The nasty version soaked the
CPU till it's ticks were almost up, the nice version suspended between
the iterations of 'for o in [#0..max_object()]'.  Inside the loop I
checked for lost ownership, and queried the second server

I can't claim any heavy player testing, but I thought it worked well
enough.

    > 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.
    >
    > 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.
    >
    > But I soon realized I had in fact opened a very nasty
    > can of worms. I
    > had to add code to the server to prohibit creation of
    > local objects
    > that were children of remote objects, otherwise I would
    > have had to
    > implement a distributed database as well - which was
    > both beyond me
    > and beyond my time budget. Another problem was the permissions
    > system; how the Wizard on server A would be prevented
    > from having
    > wizard access for server B's objects, or if I decided
    > to 'trust'
    > wizard bits between servers, how to securely
    > authenticate server
    > connections.
    >
    > To cut a long story short, I eventually gave up on "good"
    > disitributed support and left it in a fairly primitive
    > state - I had
    > to ship product and it didn't look as if it would see much use.

My solution here was to create all fertile objects on both servers.  I
found that DB size didn't cause lag, it was just code activity that
did.  (Check 'help lag' on Lambda for a nicely written essay on the
subject).

Basic to all this is that you have to write your own DB, starting with
Minimal.db.  And from the start you have to set some rules on how you
do things, and stick to them.  I don't have any wizards or programmers
other than myself, so secure authentication isn't a problem for me.
Your mileage on that probably differs.  I sort of gather from your
project that you were having to supply a system that would run almost
like Lambda, with maybe some sort of educational purpose.  My focus
and requirements are probably quite different.

    > > 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.

I thought that one over some time back, and came to the conclusion
that pre-emptive is actually worse.  If you get code to run to
completion, you save yourself the taskswitching cost.  And the
taskswitching cost on LMOO is high.  Fork() and Suspend() = Lag there.

Basically, what I see is that you're going to run it anyway.  If
you're into 3 second lag, you've just got no more CPU, no matter how
you try to swap your tasks.  The *forced* collaborative multitasking
of LMOO is quite excellent I think.

Regards,

Ian.




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