[MUD-Dev] UDP Revisted

[Dave Rickey]

-----Original Message-----
From: Brian Hook <bwh at wksoftware.com>
> At 02:47 PM 10/12/01 +0000, Bobby Martin wrote:

>> Can you give me some references on why you think a reliable
>> transport layer on top of UDP would perform better than TCP?

> Nope.  I'm going based on the opinions of people I trust a lot in
> this field.  I'm not even sure that UDP w/ reliable transport IS
> any better than TCP, except for the fact that in a 3D world you
> don't need reliable data that much.  So UDP is much faster because
> of its unreliability, and you can then just stick in the
> occasional reliable packet.  That alone makes it worthwhile.

> The biggest problem with TCP in conjunction with UDP is that the
> two streams aren't in sync.  So you can easily shovel some data
> through UDP and then immediately send some more in TCP, and
> they'll arrive radically out of order from each other or with very
> different times.

The fundamental issues of TCP vs. UDP are very simple, and are only
indirectly related to "reliability".

TCP delivers all packets, and delivers them in order.  This is good
for file transfers and such, because it allows you to stream
directly from a socket to memory to file system without worrying
about data integrity.  However, this has it's built-in downside: It
will *only* deliver packets in order, if you are sending packets 1,
2, 3, 4, and packet 2 doesn't make it, packets 3 and 4 will be held
until packet 2 *does* arrive.

In a file transfer, this is no big deal, packets 3 and 4 are there,
and will get delivered without retransmission, so losing packet 2
doesn't matter much.  If the loss rate is high enough, it can be bad
because the sender will only stream so many packets without getting
an ACK, so the back-and-forth of lost packets and lost ACK's can
degrade the throughput well beyond the impact of simple packet loss.

But in a game, a single dropped packet over a modem connection in a
TCP stream can mean 1-3 seconds of no updates.  PL rates as low as
2-3% can rend er a game based on TCP unplayable (most interstate and
almost all international IP connections have at least that level of
PL).

UDP datagrams, on the other hand, don't care if the other packets
arrive at all.  They won't be held up if the packet ahead of them
didn't arrive.  However, because you need to use a small packet (to
avoid fragmentation), you tend to send very discrete datasets in one
packet.  This packet has the XYZ, health, and vector for mob X, this
one has the HP levels for your group, and so on.  These packets
still need to arrive, random chance could lead to the packets
informing you that you were about to die being dropped 10 times in a
row.

So you number your packets, and count them, and using a TCP stream
inform the other end of the connection "packet 17 did not arrive".
Using TCP for this purpose keeps you from having to error-check your
error-checking (which would itself need it's own error
checking....).  It eventually gets this message and retransmits
packet 17.  Now, the tricky part here is to be sure not to
over-write the data delivered by packet 63 (which is a more recent
and accurate version of the same data) with that from 17.  This is
essentially just a bunch of stacks, where lower-numbered datagrams
cannot over-write more recent ones.

So the information received over UDP is not guaranteed to be
complete, but it is guaranteed to be timely, and vice-versa for TCP.
For most applications in games operating in anything approaching
real-time, timely trumps complete.

Camelot uses both UDP and TCP normally, but is capable of operating
on either one alone (with some degradation in either case).  If the
system is operating purely on a TCP stream, players witness bursts
of lag, if it is purely on UDP they see jumpiness and unreliability
from health-bars, damage messages, and NPC/Player movement.  Both
are usually problems with either firewalls or routers between them
and the game servers.

--Dave Rickey

_______________________________________________
MUD-Dev mailing list
MUD-Dev at kanga.nu
https://www.kanga.nu/lists/listinfo/mud-dev