Main differences:
TCP: Guaranteed delivery, in-order-arrival, connection-based, compressed automatically on slow connections (99% of 56k modems do significant TCP compression - but you don't notice if you download a ZIP file; you do when you download TXT files).
UDP: One-way-only (cannot respond down the same channel), connectionless (slight reduction in overhead), does IPv4 broadcast
When you say "one-way-only" you make it seem like a negative. There's just no concept of a channel to respond down. Just a nit-pick...
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).
yes and no. if you need a generalized solution that you can use in all kinds of situations, it's going to be difficult to beat TCP. on the other hand, the specialized conditions a particular game (or class/genre of games, perhaps) can be designed for, IMO.
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.
Just because TCP has 22 states does not mean that another go at guarantees needs it!
3. TCP s 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.
UDP and TCP both use the same type of packets. When TCP is *slower* (which is farily often), it's usually because of its various net congestion algorithms -- which aren't really a good thing for gaming. And UDP is no more or less efficient than TCP.
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.
agreed..
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)
These protocols, unless they are running at the OS level, are not necessarily going to be running any better than something you roll yourself. And chances are, they probably aren't optimized for gaming.
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?
).
If you know of anything that is particularly well done for gaming (and is implemented in Java!) I'd love to hear about it.
Show Posts
damn you and your math. 
