Net protocols for MUDing (was: Moore's Law sucks)

[s001gmu at nova.wright.edu]

On Mon, 23 Feb 1998 coder at ibm.net wrote:

> 
> On 20/02/98 at 02:35 AM, Jon Leonard <jleonard at divcom.umop-ap.com> said:
> >On Sun, Feb 15, 1998 at 11:55:11PM +0000, coder at ibm.net wrote: > On
> >14/02/98 at 01:58 AM, Adam Wiggins <nightfall at user2.inficad.com> said: > 
> 
> >> It makes a lot more sense to me to move away from TCP for MUD clients, and
> >> instead look to UDP and design the client and server to be tolerant of
> >> dropped packets.  Sure, things will get a bit jerky of occassion, but it
> >> sure beats waiting for the time-out and re-send of a dropped packet.
> 
> >I'd be extremely reluctant to do this.  It's very easy to redesign TCP
> >badly, and nearly impossible to do better.
> 
> No, you misunderstand.
> 
> I am proposing that MUD clients move to a protocol and data model which is
> tolerant of data loss.  If packets get lost, or arrive far to late, the
> client won't care and will continue to offer a decent representation of
> what is happening in the game.  The main problem with telnet lag is *not*
> latency but dropped packets -- the whole damn client freezes while
> awaiting the lost packet.  Instead have the client be predictive and work
> on a best-effort basis.  It works with the data it gets, and ignores or
> attempts to generate the data it never sees for whatever reason.
> 
> Raph has commented that UOL's client does this in some areas.

Any interested parties may want to look at the IEEE DIS (Distributed
Interactive Simulation) standard (Std. 1278.1-1995 and related docs).  It
deals heavily with maintaining the simulation state across multiple
machines with unreliable network connections.  Nothing overly
revolutionary, but it lays out a lot of things in one place.
I've been working with it a lot at work the past year or so and will
probably unconscoiusly steal a lot of it's ideas.  :)
 
> >For example, TCP has some fairly nice properties for slowing
> >transmissions during times of high load.  Running a UDP MUD on an
> >overloaded network could easily be a major contributor to that overload,
> >and keep it from getting better.
> 
> The key feature of TCP which I'd remove would be the error correction. 
> Given a predictive client its both unecessary and counter-productive.

it makes for very odd entity behavior if you leave it in... aye.  :)

-Greg