aboutsummaryrefslogtreecommitdiff
path: root/pipermail/nel/2000-November/000049.html
diff options
context:
space:
mode:
authorneodarz <neodarz@neodarz.net>2018-08-11 20:21:34 +0200
committerneodarz <neodarz@neodarz.net>2018-08-11 20:21:34 +0200
commit0ea5fc66924303d1bf73ba283a383e2aadee02f2 (patch)
tree2568e71a7ccc44ec23b8bb3f0ff97fb6bf2ed709 /pipermail/nel/2000-November/000049.html
downloadnevrax-website-self-hostable-0ea5fc66924303d1bf73ba283a383e2aadee02f2.tar.xz
nevrax-website-self-hostable-0ea5fc66924303d1bf73ba283a383e2aadee02f2.zip
Initial commit
Diffstat (limited to '')
-rw-r--r--pipermail/nel/2000-November/000049.html92
1 files changed, 92 insertions, 0 deletions
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 @@
+<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
+<HTML>
+ <HEAD>
+ <TITLE> [Nel] Ok, some food for your toughts</TITLE>
+ <LINK REL="Index" HREF="index.html" >
+ <LINK REL="made" HREF="mailto:archer%40nevrax.com">
+ <LINK REL="Previous" HREF="000045.html">
+ <LINK REL="Next" HREF="000046.html">
+ </HEAD>
+ <BODY BGCOLOR="#ffffff">
+ <H1>[Nel] Ok, some food for your toughts</H1>
+ <B>Vincent Archer</B>
+ <A HREF="mailto:archer%40nevrax.com"
+ TITLE="[Nel] Ok, some food for your toughts">archer@nevrax.com</A><BR>
+ <I>Mon, 20 Nov 2000 17:03:35 +0100</I>
+ <P><UL>
+ <LI> Previous message: <A HREF="000045.html">[Nel] Ok, some food for your toughts</A></li>
+ <LI> Next message: <A HREF="000046.html">[Nel] Release Schedule and some questions ?</A></li>
+ <LI> <B>Messages sorted by:</B>
+ <a href="date.html#49">[ date ]</a>
+ <a href="thread.html#49">[ thread ]</a>
+ <a href="subject.html#49">[ subject ]</a>
+ <a href="author.html#49">[ author ]</a>
+ </LI>
+ </UL>
+ <HR>
+<!--beginarticle-->
+<PRE>According to Thierry Mallard:
+&gt;<i> Just two little remarks here :
+</I>&gt;<i>
+</I>&gt;<i> 1/ the message should be more state-ish the action-ish here :
+</I>&gt;<i> &quot;you now have 37 HP&quot; more than &quot;you lost 5 HP&quot; : one is skippable, the other
+</I>&gt;<i> is not.
+</I>
+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, &quot;correcting&quot; 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 &quot;HP update&quot; above. You may send &quot;X now has 37 HP&quot;
+&quot;X now has 33 HP&quot;, &quot;X now has 30 HP&quot;, 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).
+
+&gt;<i> 2/ the order is not necessary I think, but more the delay between them. The
+</I>&gt;<i> network speed may compensate the apparent disorder : if there's only 13 ms
+</I>&gt;<i> between the events you mentionned, the player may probably not notice. But if
+</I>&gt;<i> that's 1.5 seconds, that's another problem ... ;-)
+</I>
+If you use two streams, you also need to guarantee an order between both.
+It wouldn't do to receive &quot;X has 35 HP&quot; thru TCP and &quot;X has 38 HP&quot; thru UDP.
+So all state update messages also need to carry out a timestamp so that,
+when your client parses the &quot;X has 35 HP&quot; message because your network stack
+delivered this first, he'll be able to ignore the &quot;X has 38 HP&quot; 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: <A HREF="mailto:archer@nevrax.com">archer@nevrax.com</A>
+
+Nevrax France. Off on the yellow brick road we go!
+
+</pre>
+
+<!--endarticle-->
+ <HR>
+ <P><UL>
+ <!--threads-->
+ <LI> Previous message: <A HREF="000045.html">[Nel] Ok, some food for your toughts</A></li>
+ <LI> Next message: <A HREF="000046.html">[Nel] Release Schedule and some questions ?</A></li>
+ <LI> <B>Messages sorted by:</B>
+ <a href="date.html#49">[ date ]</a>
+ <a href="thread.html#49">[ thread ]</a>
+ <a href="subject.html#49">[ subject ]</a>
+ <a href="author.html#49">[ author ]</a>
+ </LI>
+ </UL>
+</body></html>