diff options
| author | neodarz <neodarz@neodarz.net> | 2018-08-11 20:21:34 +0200 |
|---|---|---|
| committer | neodarz <neodarz@neodarz.net> | 2018-08-11 20:21:34 +0200 |
| commit | 0ea5fc66924303d1bf73ba283a383e2aadee02f2 (patch) | |
| tree | 2568e71a7ccc44ec23b8bb3f0ff97fb6bf2ed709 /pipermail/nel/2000-November/000049.html | |
| download | nevrax-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.html | 92 |
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: +><i> Just two little remarks here : +</I>><i> +</I>><i> 1/ the message should be more state-ish the action-ish here : +</I>><i> "you now have 37 HP" more than "you lost 5 HP" : one is skippable, the other +</I>><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, "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). + +><i> 2/ the order is not necessary I think, but more the delay between them. The +</I>><i> network speed may compensate the apparent disorder : if there's only 13 ms +</I>><i> between the events you mentionned, the player may probably not notice. But if +</I>><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 "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: <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> |