[Home] [Groups] - Message: [Prev in Group] [Next in Group]
4689: Re: [MUD-Dev] Net protocols for MUDing (was: Moore's Law sucks)
[Full Header] [Plain Text]
From: Vadim Tkachenko <vadimt@4cs.com>
Newsgroups: nu.kanga.list.mud-dev
Date: Mon, 23 Feb 1998 16:17:56 -0600
References: [1]
Organization: Kanga.Nu
coder@ibm.net wrote:
>
> 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.
Coming from the other side - the top: server to client communication
shouldn't rely on transaction-based protocol, but on notification-based.
Then, slowly, we will come down...
There is a Russian joke, that expression about slowly coming down is
from it, I will publish it on explicit permission.
> J C Lawrence
--
Still alive and smile stays on,
Vadim Tkachenko <VadimT@4CS.Com>
--
UNIX _is_ user friendly, he's just very picky about who his friends are