From 0ea5fc66924303d1bf73ba283a383e2aadee02f2 Mon Sep 17 00:00:00 2001 From: neodarz Date: Sat, 11 Aug 2018 20:21:34 +0200 Subject: Initial commit --- pipermail/nel/2000-November/000049.html | 92 +++++++++++++++++++++++++++++++++ 1 file changed, 92 insertions(+) create mode 100644 pipermail/nel/2000-November/000049.html (limited to 'pipermail/nel/2000-November/000049.html') diff --git a/pipermail/nel/2000-November/000049.html b/pipermail/nel/2000-November/000049.html new file mode 100644 index 00000000..14e242db --- /dev/null +++ b/pipermail/nel/2000-November/000049.html @@ -0,0 +1,92 @@ + + + + [Nel] Ok, some food for your toughts + + + + + + +

[Nel] Ok, some food for your toughts

+ Vincent Archer + archer@nevrax.com
+ Mon, 20 Nov 2000 17:03:35 +0100 +

+
+ +
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!
+
+
+ + +
+

+ -- cgit v1.2.1