From 0ea5fc66924303d1bf73ba283a383e2aadee02f2 Mon Sep 17 00:00:00 2001 From: neodarz Date: Sat, 11 Aug 2018 20:21:34 +0200 Subject: Initial commit --- pipermail/nel/2001-July/000494.html | 138 ++++++++++++++++++++++++++++++++++++ 1 file changed, 138 insertions(+) create mode 100644 pipermail/nel/2001-July/000494.html (limited to 'pipermail/nel/2001-July/000494.html') diff --git a/pipermail/nel/2001-July/000494.html b/pipermail/nel/2001-July/000494.html new file mode 100644 index 00000000..5eb1404d --- /dev/null +++ b/pipermail/nel/2001-July/000494.html @@ -0,0 +1,138 @@ + + + + [Nel] TCP vs. UDP + + + + + + +

[Nel] TCP vs. UDP

+ Sal + svferro@earthlink.net
+ 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
+
+
+
+
+
+
+ + + + + + + + +
+

+ -- cgit v1.2.1