diff options
Diffstat (limited to 'pipermail/nel/2000-November/000040.html')
| -rw-r--r-- | pipermail/nel/2000-November/000040.html | 118 |
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 "do you use TCP or UDP for networking". My +initial impulse was to reply "we use RDP, of course" (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> |