nel-all
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Nel] TCP vs. UDP


From: Sal
Subject: Re: [Nel] TCP vs. UDP
Date: Fri, 6 Jul 2001 18:32:46 -0400

> In a first step, we would like to know your opinion about this choice. And
> in a next step, we'll do some test about ping/packet lost and so on to
> compare TCP and UDP, and we'll need your help to do that.
>
> Vianney Lecroart

    I've coded small scale 3d client/server systems in both TCP and UDP
while developing software for Worldforge, and have playtested both systems.
The end result was that UDP gameplay just seemed smoother, especially under
low latency/bad connections.  Even when I had inserted code to purposely
drop packets, gameplay was still surprisingly bearable.

    On my LAN or for persons with fast links to the server TCP was not
really noticeably slower, though.  So with very low latency, and little
packet loss TCP would be the better choice, but unfortunately that isn't the
case for the internet just yet.  A lot of people are behind slow links,
shared internet connections, or in unfortunate locations... for some people
overseas my TCP-based software was almost unplayable, where UDP was still at
least minimally usable.  If you guys do end up benchmarking TCP vs. UDP, be
sure to test over a simulated low-latency, and/or 'noisy' link.  Drop
packets randomly, simulate possible internet conditions.  I'm sure you will
come to the same results I did.

    The majority of problems I've had with UDP are firewall related. And
they were almost all serverside, ie a person trying to run a UDP server
behind a firewall and unable to map ports/etc. to let clients connect.
Clientside, however there was very little trouble, it worked through my
ipmasq firewall without problems, for one, and others had been testing
behind firewalls also.

    However, a bit of 'reinventing TCP' was needed for the reliable data.
This is unavoidable, some messages need to be sent and can't be
ignored/dropped. And I agree that the OS's TCP implementation is probably
more efficient than one drawn up for a video game.  But I don't think using
both UDP and TCP is worth the trouble to gain a reliable data transmission
stream.  I just don't think the performance improvement would be significant
enough to justify the implementation... Let me explain why I think so.

    Now, say you were sending a 10 MB file over the internet to a friend.
_Every_ packet must make it to the peer or the file would be corrupt. Every
packet must be acknowledged somehow, using some crc, sequence number... etc.
I haven't looked at any actual TCP implementation's source code, but I'll
bet it does all sorts of compromising between packet transmission and
acknowledgement frequency,  message sizes, etc. and over the course of
sending 10 Million packets (ok, maybe less for a 10 MB file)  it probably
saves a considerable amount of time over some dumb UDP code that
acknowledges say, every 10 packets or some other simplistic mechanism.

    Yes, in that situation, reinventing TCP would be a bad idea... and yes,
it is definately a better choice than UDP, which in fact is why almost every
internet protocol uses TCP.  But in our case we aren't sending a 10MB file,
we're sending short messages to tell the client/server something important.
ie a 'player X has died' message, which could be maybe a dozen bytes in
size. All the fancy optimization that an OS's TCP stack does over the course
of time wouldn't be of much use here.  Also, in sending a 10MB file you dont
care about latency, and you know what the next few thousand packets are
going to consist of beforehand, whereas in a video game this is not the
case. The optimizations TCP gives you would only take effect if you were
sending large, continuous blocks of data.

    So for the gameplay networking layer I suggest UDP.  The only exception
in my opinion is for things like automatic client-patching, or downloading
of media.  In that case,  having the client make an HTTP connection to a web
server, or something similair is a *much* better choice than using the
'gameplay networking' layer to send this data.

    The software I spoke of here is all in Worldforge's (www.worldforge.org)
CVS repository.  The software I tested with was XClient, and XServer, which
are both in CVS.

    The UDP networking library I created and used in XClient/XServer, which
I recommend taking a look at, is called 'XUDP' (not the library that Dave
posted about, but has the same name :-/) is also in Worldforge CVS. I
extracted the UDP networking code from the GPLed Quake1 src, and converted
it into a general C++ OO UDP networking library. It contains code for both
reliable and unreliable transmission of data.  Credit should go mostly to
John Carmack of Id software for the code. I just abstracted, and tweaked a
bit for use in an MMORPG setting. It might be helpful if you guys decide to
go with UDP for Nel.

    Anyway, sorry for the long winded rant. Hope this helps some, and keep
up the great work!

- Sal






reply via email to

[Prev in Thread] Current Thread [Next in Thread]