aboutsummaryrefslogtreecommitdiff
path: root/pipermail/nel/2000-November/000040.html
diff options
context:
space:
mode:
authorneodarz <neodarz@neodarz.net>2018-08-11 20:21:34 +0200
committerneodarz <neodarz@neodarz.net>2018-08-11 20:21:34 +0200
commit0ea5fc66924303d1bf73ba283a383e2aadee02f2 (patch)
tree2568e71a7ccc44ec23b8bb3f0ff97fb6bf2ed709 /pipermail/nel/2000-November/000040.html
downloadnevrax-website-self-hostable-0ea5fc66924303d1bf73ba283a383e2aadee02f2.tar.xz
nevrax-website-self-hostable-0ea5fc66924303d1bf73ba283a383e2aadee02f2.zip
Initial commit
Diffstat (limited to '')
-rw-r--r--pipermail/nel/2000-November/000040.html118
1 files changed, 118 insertions, 0 deletions
diff --git a/pipermail/nel/2000-November/000040.html b/pipermail/nel/2000-November/000040.html
new file mode 100644
index 00000000..2d2d9e3d
--- /dev/null
+++ b/pipermail/nel/2000-November/000040.html
@@ -0,0 +1,118 @@
+<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
+<HTML>
+ <HEAD>
+ <TITLE> [Nel] Ok, some food for your toughts</TITLE>
+ <LINK REL="Index" HREF="index.html" >
+ <LINK REL="made" HREF="mailto:archer%40nevrax.com">
+ <LINK REL="Previous" HREF="000034.html">
+ <LINK REL="Next" HREF="000041.html">
+ </HEAD>
+ <BODY BGCOLOR="#ffffff">
+ <H1>[Nel] Ok, some food for your toughts</H1>
+ <B>Vincent Archer</B>
+ <A HREF="mailto:archer%40nevrax.com"
+ TITLE="[Nel] Ok, some food for your toughts">archer@nevrax.com</A><BR>
+ <I>Thu, 16 Nov 2000 16:12:16 +0100</I>
+ <P><UL>
+ <LI> Previous message: <A HREF="000034.html">[Nel] Flexibility (oops)</A></li>
+ <LI> Next message: <A HREF="000041.html">[Nel] Ok, some food for your toughts</A></li>
+ <LI> <B>Messages sorted by:</B>
+ <a href="date.html#40">[ date ]</a>
+ <a href="thread.html#40">[ thread ]</a>
+ <a href="subject.html#40">[ subject ]</a>
+ <a href="author.html#40">[ author ]</a>
+ </LI>
+ </UL>
+ <HR>
+<!--beginarticle-->
+<PRE>One thing from previous questions that wasn't much developped upon.
+
+Networking.
+
+The original question was &quot;do you use TCP or UDP for networking&quot;. My
+initial impulse was to reply &quot;we use RDP, of course&quot; (for those who do not
+know what RDP is, check /etc/protocols, number 27). But alas, Vianney beat
+me to the answer, so I have to be truthful.
+
+The question is: what do you use networking for, and why does the question
+on the use of TCP vs the use of UDP arises?
+
+Because, in most protocols design, this question never arises: one is clearly
+superior to the other. Why is that the question stands for a MMOG?
+
+If you look at the information elements that have to be transmitted from a
+client to the server and back, you see that they can be somehow separated
+across two different categories:
+
+1) Long-lived elements of information
+and
+2) Short-lived elements of information
+
+You may also separate on a different axis
+
+1) Uncorrectable elements of information
+and
+2) Correctable elements of information
+
+Uncorrectable elements of information are elements whose omission render the
+game state incompatible between client and server and require the transmission
+of said element, while correctable information can be overriden by a different
+game element.
+
+A few examples:
+
+- NPC X is dead: this is a long-lived/uncorrectable element
+- critter C has N hp: this is a long-lived/correctable element
+- critter C is at X/Y/Z facing direction D: this is short-lived/correctable
+- I am casting spell C: this is a long-lived/uncorrectable element
+
+Note that I can't find an example of short-lived, yet uncorrectable element.
+Any ideas?
+
+What do you face here? You face very different information elements. Some
+MUST be there for the world to make sense. So you have to guarantee their
+transmission: TCP makes sense. On the other hand, you have some that are
+quickly obsolete, and do not matter when lost. For them the whole TCP
+retransmission/guarantee of delivery is useless and a waste of ressources.
+
+So how do you design your protocol. You can take the short, easy route:
+use TCP (and lose performance for your position updates - which are by far
+the most numerous elements you get). 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).
+
+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).
+
+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).
+
+--
+Vincent Archer Email: <A HREF="mailto:archer@nevrax.com">archer@nevrax.com</A>
+
+Nevrax France. Off on the yellow brick road we go!
+
+</pre>
+
+
+
+
+<!--endarticle-->
+ <HR>
+ <P><UL>
+ <!--threads-->
+ <LI> Previous message: <A HREF="000034.html">[Nel] Flexibility (oops)</A></li>
+ <LI> Next message: <A HREF="000041.html">[Nel] Ok, some food for your toughts</A></li>
+ <LI> <B>Messages sorted by:</B>
+ <a href="date.html#40">[ date ]</a>
+ <a href="thread.html#40">[ thread ]</a>
+ <a href="subject.html#40">[ subject ]</a>
+ <a href="author.html#40">[ author ]</a>
+ </LI>
+ </UL>
+</body></html>