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

[Adam Wiggins]

On Thu, 10 Sep 1998, J C Lawrence wrote:
> 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.  

This is a tough one.  In the end, having a slow connection will suck for
the client, no matter what you do.  But there are a few neat tricks which
can alliviate their misery a small bit.

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

...in effect, the code the client is running is very similar, perhaps
identical, to that the server is running - it just knows a lot less about
the game world, and always defers to the server in case of disagreement.

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

I think you can choose sample times which will get you enough information
to work with: ie, if a certainly player has consistantly getting sharp
connection hangups which last multiple seconds with no packet
comminucation whatsoever, the game could choose to not let them into a
high-speed area (say, a quake-style arena), or it could be as simple as a
lag-o-meter that the player can check.  That is to say, in a text mud
people have a very good feel for their connection, sine they see the
content of the packets arrive directly.  Frequently people will say, "No,
I don't want to go to high-level area X right now...I'm lagging too hard
and will probably get into trouble."  In a game which is translating
packets into more subtle data and doing motion prediction, the game
continues to run at 30fps even when there are no packets coming in.  Thus
the player doesn't have a feel for what kind of lag they are in until they
start shooting at things and missing because they aren't where they think
they are.

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

I was futzing around with UDP a few months back after chatting with some
folks about it at CGDC.  IMO as soon as you go to a non-text based system
where packets are more of an object-update style, UDP can solve a lot of
problems for you.  I doesn't guarentee in-order devivery, or even delivery
at all.  However, in a realtime simulation, you could care less about
where an object was ten seconds ago - what you care about is where it is
*now*, and waiting for the old packets that didn't make it to get resent
is a waste of time.  Consider:

  Buffy is flying her sandskimmer due east across the desert.
  Boffo is observing.
  Buffy veers to the left.
  Server sends a packet to Boffo to indicate Buffy's new position and
direction of motion.
  On the way to Boffo's machine, the server's update packet about Buffy's
position gets hung up.
  Buffy veers to the right.
  Server sends a new packet with Buffy's new position and direction of
motion.

At this point neither the client nor the server cares about that hung-up
packet making it through; but with TCP, you have to wait for it.  With UDP
you can just forget about it.

This, of course, assumes that the objects complete state is stored in each
packet.  If packets are more like state deltas (ie, "I just turned left",
"I just moved forward") this won't work.

Although this isn't terribly useful for a traditional text-based mud, you
could probably still get some net optimization with a custom client using
UDP, doing its own ack'ing.  Sending messages in packet-sized chunks with
predictable id numbers (ie, each one is the previous id + 1), you could
avoid the massive resending you get with TCP when the net gets hung up,
since TCP actually restarts at the first unacked byte.  If you packetized
it, you could queue up a set of received messages until ever message up to
a certain number has been received.

For example:

   Server fires messages 1, 2, 3, 4, 5 and 6 to the client.

   Client receives messages 1, 4, and 5.  It sends a status message to the
server indicating it has recieved messages 2 - 3 and the highest message
it has received is 5.  It outputs message 1 to the player and queues up 4
and 5.

   Server resends 2 and 3.

   Client receives 2 and 3 and outputs them to the user, along with 4 and
5 (since all the intervening packets have been resolved).

   Server times out (highest packet received == 5, highest packet sent ==
6) and resends message 6.


I doubt this would be worthwhile if you're doing straight text, since
distribution a telnet which looks effectively just like telnet (to the
user) and works only with your mud and only for the platforms you happen
to have access to would be a big deterent from people playing your game.
But if you already have a client which is largely based on scrolling text
(such as that old TSN game, Shadow of Yserbius), you might as well.

> > 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 recommend an archive search for "Armageddon" and "uncrashable".

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

Also mentioned in the "uncrashable mud" thread.

> > 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?

I assume he meant a generic initialization file of some sort, the actual
format is probably not terribly relevant.

Adam