aboutsummaryrefslogtreecommitdiff
path: root/pipermail/nel/2001-July/000484.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/2001-July/000484.html
downloadnevrax-website-self-hostable-0ea5fc66924303d1bf73ba283a383e2aadee02f2.tar.xz
nevrax-website-self-hostable-0ea5fc66924303d1bf73ba283a383e2aadee02f2.zip
Initial commit
Diffstat (limited to '')
-rw-r--r--pipermail/nel/2001-July/000484.html122
1 files changed, 122 insertions, 0 deletions
diff --git a/pipermail/nel/2001-July/000484.html b/pipermail/nel/2001-July/000484.html
new file mode 100644
index 00000000..bbe419dc
--- /dev/null
+++ b/pipermail/nel/2001-July/000484.html
@@ -0,0 +1,122 @@
+<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
+<HTML>
+ <HEAD>
+ <TITLE> [Nel] TCP vs. UDP</TITLE>
+ <LINK REL="Index" HREF="index.html" >
+ <LINK REL="made" HREF="mailto:archer%40frmug.org">
+ <LINK REL="Previous" HREF="000480.html">
+ <LINK REL="Next" HREF="000486.html">
+ </HEAD>
+ <BODY BGCOLOR="#ffffff">
+ <H1>[Nel] TCP vs. UDP</H1>
+ <B>Vincent Archer</B>
+ <A HREF="mailto:archer%40frmug.org"
+ TITLE="[Nel] TCP vs. UDP">archer@frmug.org</A><BR>
+ <I>Thu, 5 Jul 2001 17:50:31 +0200</I>
+ <P><UL>
+ <LI> Previous message: <A HREF="000480.html">[Nel] TCP vs. UDP</A></li>
+ <LI> Next message: <A HREF="000486.html">[Nel] TCP vs. UDP</A></li>
+ <LI> <B>Messages sorted by:</B>
+ <a href="date.html#484">[ date ]</a>
+ <a href="thread.html#484">[ thread ]</a>
+ <a href="subject.html#484">[ subject ]</a>
+ <a href="author.html#484">[ author ]</a>
+ </LI>
+ </UL>
+ <HR>
+<!--beginarticle-->
+<PRE>According to Nicolas Hognon:
+&gt;<i> &gt; As you perhaps know, we only use TCP/IP (for server-server communication,
+</I>&gt;<i> &gt; but also for the client-server connection) and we currently think more and
+</I>&gt;<i> &gt; more about replacing the TCP client-server connection with a UDP one.
+</I>&gt;<i>
+</I>&gt;<i> You mean you are thinking about creating a tinny TCP over UDP.
+</I>&gt;<i> If you want to do that i'm not sure it's a good idea.
+</I>
+Hi. And first, I confirm I'm the same Vincent Archer that had @nevrax.com,
+but I no longer work there. Just resubscribed in time to see the discussion.
+
+I had a vulgarisation post on the topic on one yahoogroups (Dark Age of
+Camelot), but you can't access it without subscribing, so I'll summarise
+the thing.
+
+&gt;<i> Tip 7 : Don't Underestimate The Performance of TCP
+</I>&gt;<i> Tip 8 : Avoid Reinventing TCP
+</I>
+That's good advice... if you have the objectives of TCP in mind. You don't.
+In theory.
+
+Pros of TCP:
+
+- Reliable
+- Optimised over 20 years of programming
+- Fast for development
+- Most of the firewalls/telecom eqpt out hereare optimised for TCP protocols;
+ I know several IP providers who drop anything non-TCP based first when they
+ suffer congestion on their routers.
+
+Cons of TCP:
+
+- TCP is stream-based, the unit is the byte. You need to provide your own
+ packet framing, as you may, with one read call, catch part of a packet,
+ an entire packet, or multiple packets at the same time.
+- TCP has its own model for retransmission of data; you have minimal to no
+ input on that model's behaviour. And the model is geared to the transmission
+ of bulk data. There is one bit to indicate &quot;interactive data&quot; in the TCP
+ protocol; no common equipment I know out there uses or checks that bit.
+- TCP is strictly sequential: there is no way to access data &quot;as soon as
+ received&quot;, or to ignore/discard &quot;obsolete data&quot;: each data chunk must be
+ received, processed (at least at the framing level 5 layer, if you follow
+ the OSI layer model) before the next one.
+
+The last item in the list is what makes everyone look toward UDP (or any
+other IP-level protocol in fact, but routers and firewalls are usually
+disposed to treat more kindly UDP protocols than pure IP ones) for any
+application with real time constraints where:
+
+1: The exact ordering of data isn't a strong requirement
+2: The immediate processing of received data is highly desirable
+
+The real trap, as you underline, is when people design their own protocol
+over UDP and end up using the same - unconscious - model as TCP; this
+often leads to a &quot;poor man's TCP&quot; protocol that address none of the cons
+while providing none of the pros.
+
+To be efficient, any UDP-based protocol needs to be highly aware of the
+data semantics (not just syntax - i.e. format - but semantics - i.e. meaning)
+of what it carries. Which makes it very complex and usage-specific; you
+cannot plug in a &quot;random UDP protocol&quot; in your app (in this case, the
+client-server part of NeL architecture). If you design the protocol in
+complete isolation of the application (the MMOG) inside, better go directly
+to TCP; it won't be worse than anything you'll design. And it's already
+made and tested.
+
+Then, there's the whole problem of kernel resources devoted to TCP stack.
+I pass here; I'm not a kernel developper.
+
+(but anyone who plays AO knows the problems you can have merely to *connect*
+ to the game at times)
+
+--
+ Vincent Archer Email: <A HREF="mailto:archer@frmug.org">archer@frmug.org</A>
+
+All men are mortal. Socrates was mortal. Therefore, all men are Socrates.
+ (Woody Allen)
+
+</pre>
+
+
+<!--endarticle-->
+ <HR>
+ <P><UL>
+ <!--threads-->
+ <LI> Previous message: <A HREF="000480.html">[Nel] TCP vs. UDP</A></li>
+ <LI> Next message: <A HREF="000486.html">[Nel] TCP vs. UDP</A></li>
+ <LI> <B>Messages sorted by:</B>
+ <a href="date.html#484">[ date ]</a>
+ <a href="thread.html#484">[ thread ]</a>
+ <a href="subject.html#484">[ subject ]</a>
+ <a href="author.html#484">[ author ]</a>
+ </LI>
+ </UL>
+</body></html>