[MUD-Dev] Re: [IDEAS] Starting from scratch

[J C Lawrence]

On Wed, 05 Aug 1998 20:15:17 -0500 
Franklyn Colebrooke,<colebrookef at post.uwstout.edu> wrote:

> The idea I have in mind is to create a server that robust
> enough to do several things: 1. maintain quality connections with
> players in such a manner that it will actively ping the players and
> drop anyone within the admin's described margins. If not drop them,
> then to put them on a holding queue until the connection improves.

Translation: Attempt to handle network lag and latency in an
intelligent manner.  

There are a whole lot of possible approaches, all with trade-offs.
One of the old standards is using dead recking and other predictive
algorithms to update client displays with where other objects are
likely to be along with what they are likely to be doing (much tougher
-- definite AI candidate).  This allows the frequency and accuracy of
inter-client updates to fall without (significantly) impacting the
perceived responsiveness of the game.

  The problem of course are the "jumps" when the predicted states are
resolved against the actual states (eg local client lags, predicts
motions of other options, comes out of lag and finds that its
predictions were not accurate, ditto for remote clients and your
perception of them).  NB This bas heeb discussed (briefly) in the
archives along with such concepts as how to resolve critical events
(does a missile impact an enemy ship or not when the position of both
is possibly predictive), and with the use of non-error correcting
protocols to allow cheap fail-overs and predictive kick-in for lost
frames.

But, getting back to your prorposal of degrading the player's state in
the game world dependant on the state of his net connection: You're
asking for trouble.  Not technically mind you, but socially.  Players
will notice the feature, will come to rely on it, and will then find
it doesn't work.  Why doesn't it work?  Its unreliable.  Latency
changes are highly transitory and typically have extremely sharp
corners (ie they don't build up or fall down slowly -- they're
typically instant on/off situations, square waves as it were).  This
means that unless your sample happens to hit during the event you
won't detect it.  This also means you either sample with a very high
frequency (and drown those on slow connections and cause your own lag
conditions thru bandwidth consumption) or sample infrequently and
accept fairly bad average cases of undetected lag.

Further, the main "lag" problem with telnet-based MUD clients
(actually with TCP based clients) is not actually lag.  Its dropped
packets.  The old classic of the telnet session hanging for several
seconds before "coming back to life" is not caused by lag (ie high
ping time) but by one of the telnet packets being lost en route, the
protocol having to wait until timeout, and the packet to be resent
(successfully).  During this whole time the average ping time between
the ends can approximate 0ms.

Translation: The problem is in TCP, not in 'net routing and traffic
storms.  Your problem is to decide whether or not data correctness (no
dropped or lost packets) is more important than responsiveness, or
even whether you can't multiplex your data connections and
multi-thread your state machines to asynchronously accept updates from
your data connections and thus allow your data connections to rely on
TCP error correction.

> 2. I would like to be able to attach muds to the server as nodes. 

Why not run a simple front-end daemon which mrely accepts connections
and then in turn opens connections to the actual MUD server via
streams or some other high-speed low-overhead IPC mechanism?  This way 
the MUD can go down for whatever reason, come back up, poll the
front-end, and re-establish all its connections transparently.

I'll leave the questions of retaining or regenerating server and
character state across such re-connects to you or a lter discussion.

> I've also had ideas of having the mud itself have the basics(number
> of levels, max players, number of races, etc) be read from an ini
> file. 

What possible advantage dores working from an INi file give you over
any other data storage format?

> 3. I have entertained the idea of having the server being a host to
> several 'nodes'. With the ability to have players move between nodes
> with conversions as needed. Quite a few ideas on this one.

cd UberMUD portals and COOLMUD's, umm, bugger, YO (?) protocol.  You
might also want to hit DejaNews and rec.games.mud.* for this area.
There's been a lot of discussion there (much heat, some light).

> How practical is MFC for the job or creating a server for the
> aforementioned ideas? 

No idea.

--
J C Lawrence                               Internet: claw at null.net
(Contractor)                               Internet: coder at ibm.net
---------(*)                     Internet: claw at under.engr.sgi.com
...Honourary Member of Clan McFud -- Teamer's Avenging Monolith...