[vworld-tech] Some resources for ... TCP UDP

[ceo]

Brian Hook wrote:
>>stuff is glossed over; the advice is good (e.g. "Just don't bother
>>using TCP, TCP + UDP hybrid, etc - use someone else's like ENet"),
>>but with almost no explanation of why.
> 
> 
> And one more thing -- if someone wants to summarize what they feel are 
> the non-controversial cogent points of TCP vs. UDP, I'll gladly take 
> that information and add it to the article.
> 
> Right now the biggest factor is that TCP stalls all traffic if 
> anything comes out of order.  It also does not support multichannel 
> communication, so a single lost packet can back up a bunch of 
> unrelated stuff.  There are other issues with how it handles backoff 
> and congestion control, but I don't think those are as important as 
> the reliability mechanism causing problems.

I'm a bit confused by the "does not support multichannel": that's what 
sockets were invented for, no? Are you saying that a single lost packet 
on any socket backs up all other socket comms on the same PC? If so, is 
this an OS-specific or NIC-specific problem?

Anyway, some copy/pasted stuff (see below). I've made some minor edits 
to correct mistakes I noticed just now, so I'm certainly not presenting 
this as authoritative, but I'm supplying it un-condensed, so you could 
summarise as you see fit. If you'd like it massively condensed :) I'll 
have a go later on, but too little time right now. Probably better if 
other people on this list correct and add to it, and then we'll end up 
with a concise AND ACCURATE summary :).

-----------
 From a previous summary (YMMV):

"TCP is not inefficient, it just has extra features that many games 
developers don't use and don't want. If it had two flags 
"disableInOrderDelivery" and "disableGuaranteedDelivery" it would 
probably be used for all game protocols  - most people enjoy the other 
features of TCP that UDP lacks."

-----------
In more detail (taken from the UDP v TCP thread i mentioned just now):

"Main differences:
   TCP: Guaranteed delivery, in-order-arrival, connection-based, 
compressed automatically on slow connections (99% of 56k modems do 
significant TCP compression, including headers).

   UDP: One-way-only (cannot respond down the same channel), 
connectionless (slight reduction in overhead), does IPv4 broadcast

Gotchas (PLEASE don't ignore these, they are probably the cause of the 
majority of TCP/UDP woes in games development!):

1. "Guaranteed delivery" is absolute hell to implement properly. I've 
seen dozens of "UDP with guaranteed delivery" schemes which didn't work 
properly (in fact, note: JDK 1.1.x RMI was at one point completely 
broken because it included a naive implementation of this - RMI couldn't 
be used in large production environments because it generated so many 
colliding packets that it brought down the LAN. Yuk. Unforgivably stupid 
by a company with such a strong heritage in networked computers).

2. Connection negotiation and maintenance is also not trivial.

The TCP standard implementations have a complex state-model (FSM). From 
memory (but it's been a looooong time since I looked) there are 22 
unique states that a TCP system can be in. Most of those are to do with 
guaranteed delivery and connection handling (the two bits people most 
frequently try to add to UDP). Sun's implementation broke (we think) 
because they "forgot" to include the "random-delay backoff before 
re-transmit".

Compare this with the (again from memory) four states of UDP, and you 
can see there is a LOT of work if you want to achieve the benefits of both.

3. TCP is normally as fast or faster than UDP. Normally, UDP is very 
inefficient and wastes bandwidth (no, seriously), mainly because of 
small packet-sizes. For VERY small packets, UDP is more efficient, 
because it has a much smaller constant-overhead-per-packet. From memory, 
the numbers are something like 15 bytes overhead per-packet for UDP, 
compared to about 30 for TCP. But, TCP packets can be MUCH larger, so 
that 30 bytes CAN get sent much less often.

Even games sending lots of messages per second may find TCP is 
fundamentally faster (but then they get bitten by the next problem, 
sooner or later). If you experiment on your LAN, you can often get TCP 
running faster; but don't bother - the next problem will screw you if 
you deploy your game like this.

NB: TCP gets very bad on high packet-loss connections ( > 30% ), 
especially with long RTT too.

4. The vast majority of games developers only have one problem with TCP 
(but often mistakenly believe they need more!). They need to remove the 
"in-order arrival". Whenever you hear about "TCP is sloooow" or "TCP has 
high latencies", you are listening to someone who is 99% likely to have 
bitten by this problem but not understood it.

The problem is that if you send 30 packets, and the fifth one gets 
dropped, but packets 6-10 arrive OK, your network stack will NOT allow 
your application to see those last 5 packets UNTIL it has received a 
re-transmitted packet 5.

5. Lastly, there ARE alternatives to TCP and UDP. Not surprisingly, 
since almost every game finds that neither is really good enough (the 
games that just go TCP only suffer weird stuttering, the ones that are 
UDP only often get players freezing, or their guns not firing because of 
lost packets). The last time I looked, ENet seems to be the best 
widely/freely available implementation around, but people have suggested 
several others to me, including:
    RAKnet (sp?)
    RDP (covered by an official internet RFC)

There are a LOT of commercial implementations of "the best bits of UDP 
and TCP, implemented efficiently". Most are as cheap as they should be 
(tens of dollars) given that so many companies have written their own.

There are SO many implementations lying around that unless you already 
have one, you REALLY shouldn't implement your own - there's no excuse 
(unless you enjoy pain? )."

-----------
General conclusions:

"1. TCP vs UDP: It's not a simple argument; be careful about making any 
decisions that will cost you significant effort to implement.

2. UDP + (some parts of TCP): Is VERY difficult to get right; it's one 
of the areas of programming that is still "hard", as opposed to just 
being time-consuming to get right.

3. Of the three options covered in those two points, each is suitable 
for a significant percentage of games; I say "suitable" not "perfect" - 
a perfect option is the one that is technologically best for the game, a 
suitable one is the one that is affordable, not too risky, and provides 
acceptably good performance.

4. A depressingly large number of people who offer advice on these 
topics are naive or ignorant at best (i.e. they have gaps in their 
knowledge), or just plain wrong at worst. Be careful what advice you 
take! (and as endolf discovered, it's often not as simple as just 
experimenting with the alternatives people suggested and benchmarking 
them - there are nasty non-obvious subtleties in accidentally 
mis-implementing many of the protocols)."

Adam