[Nel] Ok, some food for your toughts

[Vincent Archer]

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!