Net protocols for MUDing (was: Moore's Law sucks)
Jon Leonard
jleonard at divcom.umop-ap.com
Tue Feb 17 21:34:52 CET 1998
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:
>
> >My main problem is that even though bandwidth is increasing, hiccups are
> >just as common (if not more common) than ever. This is what makes online
> >gaming so frustrating much of the time; several second pauses on an
> >otherwise clean connection for no aparent reason. Cable modems certainly
> >won't solve this.
>
> 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.
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.
By the time you've added the key features of TCP, it'll look like TCP except
that routers, firewalls and so on won't quite know what to do with it.
It may be possible to use a few simultaneous TCP streams to get better
realtime performance. But by all means keep them open -- HTTP's continual
use of new connections is both slower and more expensive than it needs
to be.
Jon Leonard
More information about the mud-dev-archive
mailing list