[MUD-Dev] Re: Multi-Server games

[MH]

Jo Dillon wrote:
> 
> MH (michael at sparta.mainstream.net) spake thusly:
> > Just keep the player/object on the original server until the new server
> > verifies that it has taken possession of the player/object.  Something
> > along the lines of:
> >
> > The international highway:
> >
> > You see a signpost here, marking where Bubbaland leaves off and
> > Boffoworld begins.
> >
> > > walk east  (to Boffoland)
> >
> > <remote server SEGV's>
> > <local server fails to recieve confirmation of remote server's
> > acceptance of player>
> > <local server puts player back where he/she was, takes necessary visual
> > steps>
> >
> > Suddenly, a great chasm appears between you and Boffoland.  You won't be
> > going *there* for a while...
> >
> > > curse
> > You swear angrily.
> 
>   This is exactly what I do, as a matter of fact. But what if things fail
> halfway through transferring a group of objects? (I.e. Bubba is transported
> but failure happens halfway through transferring the things he's carrying?)

If the local server is going to send things as a group, it can do
something like this:

<local-to-remote: Sending objects..>
<send:Buffa, foo, bar>
<local-to-remote: End Send>
<remote-server: pick up any sockets associated with the objects>
<remote-to-local: transfer successful>
<local server: wipe objects from local database>

Basicly, when the local server sends stuff over to a remote server, it
sends things until it is finished, and then asks for confirmation. 
Alternatively, it gets confirmation after each object, but does not wipe
its own copy until it has recieved confirmation on the very last object
to be sent.  If something happens halfway through, Bubba finds that he's
still on the local server, staring out over the chasm.

> And what happens if something nasty happens between the time when the
> object is linked into the new node's database and the acknowledgement is
> sent?

That depends on what you mean by the word "nasty".  If the remote server
SEGV's, then whatever is in its database is moot, as far as the players
are concerned, and Bubba will be looking at his chasm again.  If the
remote server just messes up somehow, and fails to send confirmation, I
suppose that having two copies of Bubba could be inconvienient.  This is
basicly avoided by making sure that there is no way out of the
recieve-data-and-confirm function without sending a confirm or fail
signal.

Alternatively, you could concieveably tag each object with a special
server key, which identifies which server it origniated on, etc.  I'm
thinking about this sort of thing myself.  I want to design a system
where the client is really just a server attached to the main server(s),
and handling a relatively few objects like the player and his
possessions.  Since I'm not going to be stingy about the source, there
has to be some kind of verification process for all objects, lest
someone hack his way into having a massively powerful sword.  I was
thinking about having servers use pgp to encrypt the raw data associated
with an object, and attach a segment of that output to the object to
serve as a "signature", to verify that it has not been changed since the
server last saw it.


--
Michael Hohensee       michael at mainstream.net
http://www.geocities.com/SiliconValley/Heights/9025/
      Finger me for my PGP Public Key, or use: 
http://sparta.mainstream.net/michael/pgpkey.txt