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/2000-November/000041.html | 94 +++++++++++++++++++++++++++++++++ 1 file changed, 94 insertions(+) create mode 100644 pipermail/nel/2000-November/000041.html (limited to 'pipermail/nel/2000-November/000041.html') diff --git a/pipermail/nel/2000-November/000041.html b/pipermail/nel/2000-November/000041.html new file mode 100644 index 00000000..f77c77a7 --- /dev/null +++ b/pipermail/nel/2000-November/000041.html @@ -0,0 +1,94 @@ + + + + [Nel] Ok, some food for your toughts + + + + + + +

[Nel] Ok, some food for your toughts

+ Sal + sferro@wojo.com
+ Thu, 16 Nov 2000 12:32:09 -0500 +

+
+ +
> You can take the long, hard route:
+> use UDP (and code redundancy for the elements you need to guarantee
+> transmission of, putting some badly made subset of TCP in it).
+
+    I find it easier to put some simple checking into UDP than to manage two
+sets of sockets for each client, one TCP and one UDP.  Also the important
+data that needs reliable transmission is usually rare.... like you said,
+when someone casts a spell... and maybe chat text.  Most data in a networked
+game is usually skippable.   I think this is why most games use simple UDP,
+because of simplicity of implementation, and because there is so little data
+that needs to be sent reliable, a less-than-efficient reliable stream is
+o.k.   The strength in TCP/IP comes mostly when sending large amounts of
+data, since it makes compromises with packet acknowledgement over a period
+of time to gain its efficiency. But for short bursts of data typical for a
+MMOG it wouldn't perform significantly better.
+
+> Or you can take the smart route: use two protocol paths, one which carries
+> the correctable elements over UDP (since you don't care if you lose a % of
+> them), and one which carries the critical ones over TCP (which provides
+you
+> the service guarantee you need).
+
+    This is one possible route... not a bad one either.  There would not be
+any sort of performance loss in comparison to a pure-UDP implementation,
+since the operating system's TCP/IP implementation is probably more
+efficient than the custom UDP one.
+
+    I guess its a matter of preference, of the developers are willing to
+code something that manages two sets of sockets int the clients and servers,
+then go for it :-)
+
+> One of the minor advantages of the dual-protocol path is that it allows
+you to
+> bypass firewalls that refuse to forward UDP: you fold back the UDP
+protocol
+> path into TCP. You start losing performance, but at least, you do have a
+> way of passing thru (don't forget to make your UDP packet protocols
+> compatible with TCP streaming).
+
+    This is true.  Then again, a most of today's networked games use UDP so,
+the genre of people who would play a MMOG would probably have dealt with the
+firewall issues before, and would expect to fix their config to accomodate a
+new game.  Of course thats a slight generalization...
+
+Just adding some more food to the bowl ;-)
+-Sal
+
+
+
+ + + + + +
+

+ -- cgit v1.2.1