nu.kanga.list.mud-dev

4684: Re: [MUD-Dev] Net protocols for MUDing (was: Moore's Law sucks)

On 20/02/98 at 02:35 AM, Jon Leonard <jleonard@divcom.umop-ap.com> said:
>On Sun, Feb 15, 1998 at 11:55:11PM +0000, coder@ibm.net wrote: > On
>14/02/98 at 01:58 AM, Adam Wiggins <nightfall@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.

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

--
J C Lawrence                               Internet: claw@null.net
----------(*)                              Internet: coder@ibm.net
...Honourary Member of Clan McFud -- Teamer's Avenging Monolith...