Subject: [Nel] Ok, some food for your toughts

From: Vincent Archer <[email-masked]>
Date: 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: [email-masked]

Nevrax France.                              Off on the yellow brick road we go!

---

From: "Sal" <[email-masked]>
Date: Thu, 16 Nov 2000 12:32:09 -0500

> You can take the long, hard route:

    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.

> 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 :-)

> 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

---

From: "Vianney Lecroart" <[email-masked]>
Date: Fri, 17 Nov 2000 10:56:10 +0100

Hello,

> MMOG it wouldn't perform significantly better.

Oh really? I have not the same opinion. I think that 90% of information on a
game
are important and must be received if you don't want to have inconsistency
in the client side. the order of information are also very important. if you
receive
"you lost 5 hp" message before "you are attacked by XXX", it should be
totally
weird. I think that messages, in a role game, must be sorted and reliable
for
consistency and logical events.

>     This is true.  Then again, a most of today's networked games use UDP
so,

be careful, there more than 1 category of network game. there are MMOG and
counter strike like game (with few tens of players). for the second one udp
is a
surely useful but for MMOG, I'm not sure that the most of them are in UDP
only.

-vl

---

From: Thierry Mallard <[email-masked]>
Date: Sat, 18 Nov 2000 09:23:03 +0100

On Fri, Nov 17, 2000 at 10:56:10AM +0100, Vianney Lecroart wrote:
> [ Networking ]
> I think that 90% of information on a game are important and must be received
> if you don't want to have inconsistency in
> the client side. the order of information are also very important. if you
> receive
> "you lost 5 hp" message before "you are attacked by XXX", 

Just two little remarks here :

1/ the message should be more state-ish the action-ish here :
   "you now have 37 HP" more than "you lost 5 HP" : one is skippable, the other
   is not. 

2/ the order is not necessary I think, but more the delay between them. The
network speed may compensate the apparent disorder : if there's only 13 ms
between the events you mentionned, the player may probably not notice. But if
that's 1.5 seconds, that's another problem ... ;-)

	Shaman, 
	[ still learning to write english ... ;-) ]

-- 
Thierry Mallard              |              
GnuPG key on wwwkeys.pgp.net |
key 0xA3D021CB               |
http://thierry.mallard.com   |

---

From: Vincent Archer <[email-masked]>
Date: Mon, 20 Nov 2000 17:03:35 +0100

>    "you now have 37 HP" more than "you lost 5 HP" : one is skippable, the other

As a general rule, change of state messages are always what I termed
uncorrectable elements, while state information is, by definition,
correctable (because you can resend the same state information at any
time, "correcting" the error).

Now, some information can be expressed in terms of either state or change
of state. The choice of the type of communication between server and client
must be individually chosen for most.

An important point to keep in mind is that, for most state information
which we deliver thru UDP, you are perfectly allowed to lose some
information (since you expect it will be corrected in the near future),
but for any specific state, you must guarantee that at least some of the
updates are delivered properly.

A good example is the "HP update" above. You may send "X now has 37 HP"
"X now has 33 HP", "X now has 30 HP", but at some point, you need to ensure
that the client (since we assume that the server is the one giving the state
update) gets at least one update. So, most of these updates would be sent
using UDP, but one out of N has to be sent using TCP to ensure guaranteed
delivery (or, more typically, one every N seconds).

> that's 1.5 seconds, that's another problem ... ;-)

If you use two streams, you also need to guarantee an order between both.
It wouldn't do to receive "X has 35 HP" thru TCP and "X has 38 HP" thru UDP.
So all state update messages also need to carry out a timestamp so that,
when your client parses the "X has 35 HP" message because your network stack
delivered this first, he'll be able to ignore the "X has 38 HP" one which is
now obsolete.

Oh, and I do agree. Using pure TCP frees you from the hassles of dealing
with all that... but you relinquish a lot of control of the lag, since you
cannot control how and when the information is retransmitted.
-- 
Vincent Archer                                         Email: [email-masked]