[MUD-Dev] UDP vs TCP/IP

[Daniel.Harman at barclayscapital.com]

> From: Daniel.Harman

> Anyone got a take on UDP vs TCP for graphical MMORPGs?

> I always assumed UDP was the obvious choice for the majority of
> the data (if not all), seeing as old missed packets don't really
> need resending for a lot of the information (do you care where
> player y was standing 3 updates ago?).

> I only raise this as I hear AO is using TCP/IP and I was
> surprised. I guess it saves some work compared to UDP, you'd
> certainly have to do some reliable delivery work at the
> application level, losing chat messages etc. is just not
> acceptable.

I was going to comment about the success of AO's strategy in light
of release, but I found a post on the AO message board that says all
I was going to say. Anyway, it looks like pure TCP was a big
mistake, as the game frequently becomes irretrievably lagged out and
a packet storm ensues at both ends. Its a set up that seems designed
to catastrophically fail for everyone in a chain reaction too - once
a few people start lagging and a storm starts, others start lagging
and make it even worse. You then suffer inevitable catastrophic
failure for just about everyone connected.

oops!

8<-----------------

Paco wrote:

I posted a shorter version of this last night, but it appears to
have gone unnoticed among the flurry of other posts.

Admittedly I'm not much of a Windows guru, but from the little bit
of poking I did with netstat (-a shows all connections and -s shows
per protocol statistics) it seems to me that AO only makes use of
TCP (and not UDP or something else above IP). Can anyone confirm
this? Unfortunately my net connection is a dialup so sniffing
packets is not trivial.

While using TCP for the login and patch processes certainly makes
sense, it is very much out of place within the game given AO's
real-time nature and a lossy environment like the Internet. Games
such as Quake and EverQuest have used homebrewed protocols on top of
UDP, and other applications where timeliness matters (streaming
audio and video, etc.) have done similarly.

In layman's terms, TCP provides solutions to many of the problems
found in delivering packets through the Internet. These solutions
make network programming considerably easier, but come at a cost. It
is my belief (as well as that of other game coders, researchers and
academics) that TCP is not well suited to real-time applications
(real-time refers to the fact that obtaining a "timely" solution (or
delivering a message in a "timely" fashion) is as important as
actually producing the solution or delivering the message).

The problem here is that losing one packet delays the delivery of
all subsequent packets at the receiver. TCP provides guaranteed, in
order delivery of packets. (It does this by resending packets (at
the sender) and delaying delivery of already received packets (at
the receiver) until all earlier packets have been delivered.) This
is good for things like transferring files, where the most important
thing is that we get *everything* that was sent. On the other hand,
consider a phone call: we tolerate losses (think of the poor quality
of cell phone calls) because the most important thing is that we
keep up with the conversation - getting everything is just not that
important.

An application working on top of TCP perceives no packet loss. If a
packet is actually lost (usually dropped by a busy router somewhere
in the net), TCP will resend the packet (without any special action
on the part of the application) until one of two outcomes occurs: a
copy of the packet arrives at the receiver (in which case we go on
until another packet is lost), or a timeout occurs (in which case
the channel is reset, resulting in disconnection). This is why I
think AO does not have a packet loss meter - it would always read 0%
PL. A lag meter built on top of TCP would also not be terribly
accurate - remember that packets are artificially delayed at the
receiver (in case of packet loss or out of order delivery) because
we have to preserve the semantics of TCP (in order, guaranteed
delivery).

There is some anecdotal evidence that seems to back up these
conjectures. By now you will have noticed that some actions
(e.g. moving around, looking at your inventory, seeing battle
animations) can proceed despite lag and packet loss, while others
(e.g. sitting down/standing up, bringing up the list of items sold
by a machine, seeing the actual damage being done in battle)
cannot. You might also have noticed that when this second set of
actions "catches up", the "recovery" is very quick. By recovery I
refer to how quickly the actions occur - rather than seeing them
spread out over time, you see all the damage being done within a
second or two, or see yourself sitting up and standing down
repeatedly.

This brings me back to the lag meter and how inaccurate it
seems. Sometimes it will be green but I will be unable to interact
with the world (I will try to sit, but 30 seconds later I am still
standing). At other times it will be red but I can interact with the
world just fine (I push 'x' and my character sits right away). So
for the last day or so I have been using the sit/stand method to
gauge lag, as opposed to using the lag meter. Sit/stand seems to
work far better.

Lastly, I would like to point out what I see as an unusual
relationship between the disconnects and the zoning
problems. Whenever zoning is working fine, I seem to experience
regular disconnects. Whenever the connection is solid, I cannot
zone. This is probably just a peculiar coincidence but might be
worth looking into as well.

I certainly hope I'm wrong and I half expect that someone who groks
this will educate me. If AO does use TCP for all in-game traffic, I
think this should be explored as a major reason behind the frequent
disconnects... The solution, as I see it, would be for Funcom to
develop their own transport protocol and might require some
retooling of the client and server.

Anyways, I spent a good amount of time typing this up, and would
appreciate any comments or criticisms.
_______________________________________________
MUD-Dev mailing list
MUD-Dev at kanga.nu
https://www.kanga.nu/lists/listinfo/mud-dev