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/2001-July/000484.html | |
| download | nevrax-website-self-hostable-0ea5fc66924303d1bf73ba283a383e2aadee02f2.tar.xz nevrax-website-self-hostable-0ea5fc66924303d1bf73ba283a383e2aadee02f2.zip | |
Initial commit
Diffstat (limited to 'pipermail/nel/2001-July/000484.html')
| -rw-r--r-- | pipermail/nel/2001-July/000484.html | 122 |
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: +><i> > As you perhaps know, we only use TCP/IP (for server-server communication, +</I>><i> > but also for the client-server connection) and we currently think more and +</I>><i> > more about replacing the TCP client-server connection with a UDP one. +</I>><i> +</I>><i> You mean you are thinking about creating a tinny TCP over UDP. +</I>><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. + +><i> Tip 7 : Don't Underestimate The Performance of TCP +</I>><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 "interactive data" 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 "as soon as + received", or to ignore/discard "obsolete data": 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 "poor man's TCP" 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 "random UDP protocol" 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> |