From: oreillym@tartarus.uwa.edu.au (Michael O'Reilly)
Newsgroups: rec.games.mud.lp
Subject: Re: Distributed lpmud
Date: 14 Dec 1992 02:24:08 GMT
Organization: The University of Western Australia
NNTP-Posting-Host: tartarus.uwa.edu.au
X-Newsreader: Tin 1.1 PL5

Michael Moore (mdm@hadrosaur.cis.ohio-state.edu) wrote:
: 	Hey folks!
: 
: 	I am curious if anyone is working on a distributed lpmud?

Yes. Me. Sortof. It isn't quite an LPmud. In fact, the only similarity
is that both will be a mud. 

On the other hand, a friend of mine (hi pariah!) is working on a real
distrubted Lpmud. Being Lpmud, it is very difficult to make it
transparent (Thats why I started mine from scratch).

: I know every so often people start talking about how nice it would be
: to be able to hop from one mud to the other via "portals" or whatever,
: so I would think it might be something people would want.

Pariah's does just this. You can transparently walk back and forth
between muds, and even carry items across (if the other mud like the
item you are trying to bring in..)

: 	What I envision is a mud driver built to have these hooks.
: The central driver keeps track of the player files, and the core
: mudlib, the nexus, or whatever.  And then as the mud adds wizards,
: the administrator authorizes a portal to be placed inside the core
: mudlib which leads to the new wizards realm.  The new wizard would
: create his realm on his own machine, and it would basically be
: a clone of the central driver as far as lpc is concerned, but it
: would be slaved to the central server.  

This is close to what pariah has done. Except there is no 'central'
server as such. A central server would make the system too fragile.

: 	My hope would be that this would allow muds to be much freer
: with their wizardships.  And that it would make muds capable of
: handling hundreds of players without slowdown.  Since the wizard
: would be running a gamedriver himself, he could set limits on how
: many players could be using his area at one time, but the overall
: effect would be a distribution of the network and cpu usage to
: sites spread throughout the internet.

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. 

My mud supports truely distributed processing. (at least, it will when
I finish it).
 
: 	Most students could probably run their mini-driver without
: much concern, since it would only be handling a set number of people
: at once.  I don't think an lpmud with 10 users is going to bother
: anyone.  

Unless 200 people come over to vist those 10 ppl... 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.."

: 	There would be new problems with this system.  For example,
: if the wizard's host site is in a bad place with relation to the
: player, then they would probably not want to visit there.  But players
: could pick and choose whichever realms they felt were tolerable, and
: avoid those wizard's areas which were to lagged.
True.
 
: 	The administrators of the central driver could control which
: portals they added, and so they could provide quality control, only
: OKing something if it fits in with their theme, or whatever.
: 
: 	Who knows, if it all worked out you could have a textual
: cyberspace spread accross the internet, with hundreds of coders
: managing their own private realms, and with players free to pick
: and choose among them.  All connected together at the nexus.

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..
 
: 	I am interested in any thoughts on this subject, like if
: anyone is interested in the idea, if anyone is working on the idea,
: if there is a reason it simply won't work, further ideas, etc.....

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.

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

The solution to this is to get rid of find_object(), and ONLY allow
access to objects you know the handle of. This is fine because you
never need to search to find an object. The handle will tell you
exactly where it is. 

This also simplifies security. You have an object
that is a file-system handle. Only objects that have that handle can
access that file-system. Instant security. Strong typeing allows you
to have limited access to a file-system. You have class File_system
inherit File_sys_ro, and then if you cast file_system to file_sys_ro,
you can give away the handle safe in the knowledge that they can only
look, but not touch (Safe, as casting in the other direction is an
error. You can only cast to a super-type, not a sub-type).

This also simplifies garbage collection. You don't need the
'destruct()' kludge, and can simply deallocate object that don't have
any references. (As if there are no references, then nothing can ever
use that object again, as it can't get access to it).

: 	See ya,
: 	-Michael ( a dreamer )


Michael.
Newsgroups: rec.games.mud.lp