From: pariah@tartarus.uwa.edu.au (Michael Malone)
Newsgroups: rec.games.mud.lp
Subject: Re: DISTRIBUTED MUDDING
Date: 15 Dec 1992 06:34:20 GMT
Organization: The University of Western Australia
NNTP-Posting-Host: tartarus.uwa.edu.au

mdm@hadrosaur.cis.ohio-state.edu (Michael Moore) writes:
> a lot of stuff

The biggest problem I have with what you suggest is your
insistence on a central object. In a well designed system,
I fail to see the necessity for such an impediment.

I have written a driver which is theoretically distributed,
though still definately pre alpha. It works on the assumption
that each "trusted" node on the distributed system must be
known to its partners.

If a player steps from node DM to node PX, his inventory is
processed into an array of (file_name:mods)*. The player file
is then sent to PX, encrypted with DM's password for PX, which
only PX and DM know (this is critical to a secure transfer).
If PX receives the data, and successfully decrypts it, it must
decide whether of not to accept the character. For many reasons,
like the player's race is not valid, PX doesnt "trust" DM, or
PX is over loaded, PX may decide not to ack the transfer.
On receipt of the ack, DM deletes the players file, and
arranges for a connection between the player and PX. This is
done in one of two ways;

a) if the player has a client, then the sequence
   "@connect addr_of_PX" is sent to the players connection,
   which is then closed and forgotten about.
b) if the player doesnt have a client, DM appoints itself
   as client, connects to PX itself, and tells PX that this
   player now HAS a client.

The inventory of the player is exploded and recloned on PX.
If any object does not exist on PX, it is lost, altho the ack
to DM could have contained information on this, forcing the
object to be dropped before leaving DM

In general, we envisage distant links on the network to have
a similar distance on the mud. eg) crossing from a link in
Perth to on in Chile, would be akin to crossing a vast ocean
on the mud, so such transfers must be rare.

The client must retain information regarding the current host
that the player is connected to. eg) if I am using the Perth
mud as a client, then it must remember that I was last
connected to Chile, and immediately appoint itself as client
and connect me to Chile next time I log on.

The potential holes in the system are many, and recognized.
The most obvious is that if I choose to log onto a node in
Los Angeles, then as far as LA is concerned, I am a new
character. Verification of this, on a fragile network is
neither sensible nor expedient (remember we live in Australia,
with ONE link to the rest of the world, similar to many of
the newer additions to the net). Conflict of player names
if not a problem relevant to my driver.

A rogue host may create a character with super duper powers
and equipment. Such a rogue host would not remain trusted for
very long by many of its neighbours, and since we use a
skill based system, abuse is a pain, but not a dramatic
problem.

Wizards are handled locally. PX decides on who is a wizard on
its node, and this character may or may not be a wizard on
DM or any other node.

Transfers are not perfectly transparent. Every wizard likes
to make his own beautiful objects, like the Supreme Omnicient
Sword of the Dragon (SOSD) and this object can only be moved
to nodes that contain the source for this sword. Note that
the file_name:mods format allows for minor changes such as
a varying of the short description etc, so this problem, while
a real stumbling block is not a barricade.

What I would like to see is a far more standard approach to the
LPmud entry to network programming. For example, why doesnt
the TMI mailnet use SMTP ? It is every bit as powerful as their
own Protocol (hey! it has worked for internet for the last decade!)
and would allow trivially for a mud->net mail node, and of course
for me to connect mail to their net trivially. What is CD planning
to do exactly with their pretty UDP sockets? All my applications
require a guaranteed secure and reliable transfer. I understand that
the setting and stripped of a full duplex socket is expensive,
but it will likely be rare as well.

Anyway, just some brief thoughts on how I have tackled a
distributed system. This HAS (believe it or not!) been well
thought through, largely between myself and Xavier for the
last 2 years. Before the accusations fly, yes it is varporware.
While we have it running on Linux and Ultrix I have no intention
of releasing it until I have got a stable mudlib (and with damned
innovative releases from CD, TMI, AND Amylaar in the last month,
I am getting snowed under. sigh)

Pariah

ps: hmm, three of the four people on this discussion so far
    have had the christian name Michael. Coincidence ? or
    something far more insidious ?


------------------------------------------------------------------------
for (i=0;i<8;P("\n"),i++)
  for(j=0;j%6?(i>3?P(" "):(j==i||j==6-i?P("#"):P(" "))):P("#"),j<7;j++);

Please, dont expose our children to C ...