[Nel] TCP vs. UDP

Thu, 5 Jul 2001 17:50:31 +0200

According to Nicolas Hognon:
+> > As you perhaps know, we only use TCP/IP (for server-server communication,
+> > but also for the client-server connection) and we currently think more and
+> > more about replacing the TCP client-server connection with a UDP one.
+> 
+> You mean you are thinking about creating a tinny TCP over UDP.
+> If you want to do that i'm not sure it's a good idea.
+
+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.
+
+> Tip 7 : Don't Underestimate The Performance of TCP
+> Tip 8 : Avoid Reinventing TCP
+
+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:	archer@frmug.org
+
+All men are mortal.  Socrates was mortal.  Therefore, all men are Socrates.
+							(Woody Allen)
+
+