[Nel] Ok, some food for your toughts

[Vincent Archer]

According to Thierry Mallard:
> 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. 

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

> 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 ... ;-)

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: archer@nevrax.com

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