From: mdm@hadrosaur.cis.ohio-state.edu (Michael Moore)
Subject: DISTRIBUTED MUDDING
Organization: The Ohio State University Dept. of Computer and Info. Science
Date: Mon, 14 Dec 1992 17:36:12 GMT


>>>>>>>	Michael O'Reilly writes :

>The problem is that if all those players are in one part of the mud,
>then you lose badly. You have N machines lying idle, and 1 dying under
>the load.

	Well, this is simply a limitation you enforce.  The owner of
the mini-mud would decide how many people maximum he wanted in his world
at one time, and after that no one else could enter it.

>	 Setting arbitrary
>limits on a driver would be even worse. "Sorry, you can't go into that
>room, there are too many ppl there. Try again later.."
 
	This is exactly what I would recommend.  I don't see it being
a big problem, as long as you have the central mud tying everyone together,
they could all talk to each other and if everybody wanted to get
together they could meet in the core mud, which is expected to have a
great multitude of players.

>Forget the idea of a central server. If the server goes down, then the
>entire thing goes down. If the server gets lagged, everyone gets
>lagged..


	Well, the central server is meant to provide a theme for the
worlds, and to link them all together.  Should the central server go
down, everyone would indeed be unable to play, but this would be the
case with the current mud system anyway, so you lose nothing.

	What you gain is the ability to provide a limitless amount of
work space for the wizards.  You give them the ability to hook into
your world, provided they fit certain "guidelines".  They supply the
disk space and the cpu.  For example, on a warhammer style mud, the
central server administrators would only authorize hooks to other wizard's
realms that fit their genre.  

	The best way to work this sort of thing with regard to connections
is to avoid forcing the central server to do shuttle service.  That slows
down the server and doubles network bandwidth, and increased travel time.
If your loop goes :  player -> server -> wizard's realm -> server -> player
then you are having to use the server as a stepping stone.  This might
be necessary for telnet, but it should be possible to write a client
which knew how to reconnect to a new host as indicated by the server.
This sort of idea brings up a lot of issues, but I don't think any of
them are unworkable.  The main issue right now is the feasibility of the
idea, and whether there is a better way of doing it.

>I am working on a truely OO system. It is persistent, multi-threaded,
>and (will be) distributed. I choose to start from scratch, as LPmud is
>getting to be on it's last legs. The lack of strong typeing , and the
>horrible compiler are two of the reasons for this decision. The
>compiler you can fix, the typeing you can't.

	Well, at least for my vision, it does not matter what driver
is used.  The nicer it is to the cpu and the network, the better,
because that means more wizards can run it on their machine and
thus more worlds come into being.

>The other really big problem with Lpmud, is that 'find_object()' is an
>integrel part of the mud. This pretty much kills you as far as making
>it properly distributed goes. (Can you imagine the network traffic
>involved in doing a find_object() on a non-existant object.)


	This would definitely have to be addressed, but I don't see
how it is such a problem.  If the wizard's realms are all run under
separate drivers, then everything works fine within the locality of
the system.  You would of course have to provide the means for 
communication with the other realms, and perhaps for finding objects
in other realms (costly!!!!), but these also are not impossible to
accomplish, if done right.


>>>>>>>	Now Adam Beeman writes :

> The whole project is more than
>a little intimidating, when you think about all the different issues it
>raises.

	Most certainly.  To do this sort of thing right would require
a great deal of effort, both in coding and in the design of the system.

>I think however both you and I are
>looking for something more like an LPmud that does this, though, or we would
>be content with Cool or Unter.

	Well, I am looking for the thing which provides the most power
to its wizards.  I have to confess I have not even looked at Unter or
Cool... but I take the lazy course of logic and conclude they must not
be doing what I am thinking of or else I would have heard about it and
taken a look...

> There are several ways of doing this, and the whole process
>seems to sound like a nightmare...  I'd be glad to hear proposals on how to
>handle this.
	
	Well, in my system (with a central server glueing everything
together) you gain the ability to trust your muds.  You don't have to
worry about incompatibilities because when you were given the hook
into the central server, you agreed to use their core mudlib and adhere
to all the other guidelines they set.  

>hat the mapping could be passed from one place to another if needed.  Then,
>the only code that needs to be transferred are special cases.
	

	Well, the way I was thinking is your central server has a core
mudlib, which is indeed specific to its style, and you copy that when you
decide you want to create a realm for that server.  Everything you design
is based on that core mudlib, and so you end up transferring the code
only for those objects which are customized from the core.  All the
inheritence will work out very much in our favour in this sort of
situation, since the inheritence will still hold true in all the realms.

	One problem that springs to mind is figuring out what objects
are custom and which objects rely on other objects outside of the core.
This might be easy, I haven't coded lpc in a long time, but I think you
have to indicate which files you are inheriting from in the first place,
so it should be straightforward to make this determination....

>This raises two major issues right here.  First, maintaining a dozen nearly
>identical core mudlibs is no small task in a rapidly changing environment.
	
	This is one of the reasons I desire the central server, since it
allows for different core mudlibs.  It does limit the overall transferability
between different "central" servers, however.  

	Well, I've talked long enough... I'll let someone else take up
the podium now.  I'm putting the words "DISTRIBUTED LP" in the header
so folks not interested in this don't have to wade through it.  Better
perhaps would be a mailing list, but oh well....

	-Michael 

-- 
|\  Michael  Delbert  Moore     _   /|     Home   : (614) 471-1937         /|
| \ OSU Student  Programmer     \`o_O'     Office : (614) 292-7161        / |
| / Undergraduate CIS major       ( )      Email  : mdm@cis.ohio-state.edu\ |
|/-------------------------        U       --------------------------------\|