[MUD-Dev] Languages for MUD drivers

[Cynbe ru Taren]

"Laurent Bossavit" <bossavit at cybercable.fr> wrote:

| 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. [...]
| 
| Even assuming something like an 'object exchange protocol' [...]
| 
| 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.
| 
| [...] 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.

I'm almost tempted to quote the above in the Muq docs, as motivation
for much of Muq's design and implementation. :)

The amount of coding required to support such distribution is not
terribly large per se, but attempting to retro-fit it to an existing
design is likely to expose all sorts of suddenly inconvenient design
and implementation decisions in the existing server and db code.



| > 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 found in Muq that going pre-emptive multi-tasking and going
distributed imposed closely related requirements, and that once
having gone pre-emptive multi-tasking, the additional step to
distributed operation was not terribly difficult.  (Albeit
not trivial.)

Basically, if you're pre-emptive multi-tasking with each user
having something like a daemon thread, then user interactions
wind up taking place via messages passed back and forth between
threads anyhow, and whether there is a network serialization
step involved in the message-passing doesn't make much
architectural difference.

With Muq I added some underlying support that transparently does
de/serialization of messages passed between servers, transparent
proxy construction/dereference to make remote objects 'look'
local for typical casual application programming purposes,
Diffie-Hellmen authentication of cross-server interactions,
and two-fish encryption of the contents of server-server traffic.

The result lets the overlying Micronesia worldkit offer transparent
world distribution pretty cheaply, mainly at some cost in user-user
protocol clumsiness and of course latency for interaction with
remote objects.

The standard Muq regression test suite now includes cases which
run two and three separate Muq servers in distributed world
operation mode, with test users @who'ing, paging, saying, building
and moving without user-level distinction between local and
remote:  Exits can link rooms on different servers &tc &tc.

It works in automated testing with 2-4 uers.  It hasn't been
tested live as yet (version 0.0 -- first beta -- isn't until
99Dec29) nor have I done stress testing with dozens, hundreds
or thousands of simulated users.

I'm pretty sure there are at present some performance bugs
inhibiting scaling into that range, but I don't anticipate
any great problem tracking them down when the time comes.

  Cynbe



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