[Nel] Ok, some food for your toughts

Thu, 16 Nov 2000 16:12:16 +0100

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: archer@nevrax.com
+
+Nevrax France.                              Off on the yellow brick road we go!
+
+