MUD-Dev
mailing list archive
[ Other Periods
| Other mailing lists
| Search
]
Date:
[ Previous
| Next
]
Thread:
[ Previous
| Next
]
Index:
[ Author
| Date
| Thread
]
Net protocols for MUDing (was: Moore's Law sucks)
On Mon, 23 Feb 1998 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.
>
> 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
- Thread context:
- Re: [MUD-Dev] Moore's Law sucks (was: 3D graphics), (continued)
- Re: [MUD-Dev] Moore's Law sucks (was: 3D graphics),
Adam Wiggins nightfall#user2,inficad.com, Sat 14 Feb 1998, 09:49 GMT
- Re: [MUD-Dev] Moore's Law sucks (was: 3D graphics),
coder coder#ibm,net, Mon 16 Feb 1998, 07:38 GMT
- Net protocols for MUDing (was: Moore's Law sucks),
Jon Leonard jleonard#divcom,umop-ap.com, Fri 20 Feb 1998, 10:24 GMT
- Re: [MUD-Dev] Net protocols for MUDing (was: Moore's Law sucks),
coder coder#ibm,net, Mon 23 Feb 1998, 19:20 GMT
- Net protocols for MUDing (was: Moore's Law sucks),
s001gmu s001gmu#nova,wright.edu, Mon 23 Feb 1998, 21:15 GMT
- Re: [MUD-Dev] Net protocols for MUDing (was: Moore's Law sucks),
Vadim Tkachenko vadimt#4cs,com, Mon 23 Feb 1998, 22:18 GMT
- Re: [MUD-Dev] Net protocols for MUDing (was: Moore's Law sucks),
Adam Wiggins nightfall#user1,inficad.com, Sat 28 Feb 1998, 04:54 GMT
[ Other Periods
| Other mailing lists
| Search
]