[Nel] TCP vs. UDP

[Vincent Archer]

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)