Some name dropping here (please forgive, I feel I must make sure those who made it happen get proper credit) --
The previous posting stating that 'vonJacobson' who is really "Van Jacobson" did enable PPP link to use TCP header compression. I worked at LBNL shortly after I worked in the game biz, not in the network technologies group but I did get to know them reasonably well (http://www-nrg.ee.lbl.gov/
). They were incredibly influential in the network world, the folks who made 'traceroute', 'tcpdump', and 'libpcap', and hundreds of low level optimizations to IP stacks and tools against TCP in the 90's. Let me begin by saying that Van Jacobson is an incredibly brilliant man and did a lot of amazing and unimaginable things, he lead that group (I cannot give him the credit he deserves), however the TCP header compression was intended for very slow point-to-point links mostly which are disappearing every day and those that are not are out-optimizing his compression (e.g everyones compressing streams these days).
Back into the UDP v. TCP argument -- In the late 80's (I'll call this the pre-quake era) everything was IPX(Novell) , but there was some effort in trying to figure out what worked being converted to TCP/IP. I was fortunate enough to work with a very brave, ingenious, and adventurous lot that were trying to make games playable on the Internet -- everything was TCP then. Back in those days when one person lost the connection even in a game of backgammon, the whole game crashed (lockstep).
Later, a few innovative and ingenious souls started to realize that the problem was not nature of the network but how they were looking at the network. I personally think of Bill Lipa who was the Architect at TEN, but Quake came out a few weeks after TEN did Duke Nukem in UDP, so I'm not sure if it was Bill Lipa or John Carmack who originally thought of it first (I know I'm biased since I worked at TEN in those days, but Bill Lipa was a network proramming guru while John Carmack was a god, but mostly in graphics and non-networked game stuff).
I have to simultaneuously agree and disagree with ' blahblahblahh' . I've not read the X-wing-versus-tie-fighter article, but I have to state quite bluntly, use TCP until you understand whether to use UDP in place of TCP. There is quite simply no reason to blindly assume you will get better performance out of UDP than TCP, and using UDP will make things much more complicated.
1. "Guaranteed Delivery"
Agreed, it is generally *NOT* worth doing on your own - if you don't understand this please accept this as fact! Many, many really smart people have spent half of their lives on this and only gotten tiny advancements! If its critical your packet gets there then use TCP, and focus on your game design.
2. "Connection negotiation and maintenance is not trivial."
Agreed. Again people have spent half of their lives on this and gotten tiny advancements. Save yourself the grief and accept this as fact! Unless you want to dedicate your life to a network protocol stack, again a reason to use TCP.
3. "TCP is normally as fast or faster than UDP. "
Heres where I disagree, this depends largely on whether you are measuring as 'fast', latency or bandwidth.
"Normally, UDP is very inefficient and wastes bandwidth",
True UDP wastes bandwidth, but its in trade for latency. If the raw packet delivery is more important than the sequence or state, and the game itself can deal with these factors on a frame-by-frame basis then what a great place we've gotten to. The fact is in some games its important, in others, its not.
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, a single retransmitted packet can seem tragic for a developer trying to make their game playable across the internet. Which often makes developers inappropriately reach for UDP, thinking it will fix their problem and usually it will not. But there is something beautiful to the idea of being able to drop packet '5' and proceed that seems appealing.
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)
Ok here, fully disagree. Random replacements for to on top of of IP seem to invoke the same arguments you were posing earlier - working against your initial premise. I would say quite simply use TCP for reliable delivery, use UDP where latency is at a premium.