I think tcp have an unfair reputation. Our networks are better now then 30 years ago ... Worst case latency for tcp is like 3 seconds, compared to the packet never arriving. The trick is to hide the lag with animations. I think google, facebook, and world of warcraft use tcp for their real time apps !?
You mean the networks in particular that you use? There's a lot of varied network equipment out there. Glenn wrote this article at least 8 years ago and for the types of games he works on (realtime 64-player online FPSes), I'm sure TCP still wouldn't work as well as a UDP solution.
> The trick is to hide the lag with animations
That's an understatement. A significant amount of work needs to be done with client-side prediction in order to give the appearance of playing in real time consistently with other players.
> I think google, facebook, and world of warcraft use tcp for their real time apps
Which real time apps are you referring to? In the context of this article, Glenn is talking about soft realtime systems (30 hz updates or more). There aren't any user-facing apps from facebook or google that I'm aware of that I would call "real time". For WoW, timing is less critical than an FPS and obviously TCP works well for them.
3 seconds is 2900ms too long, a game would typically rather lose the packet rather than have it delay all transmission for that long. World of Warcraft is a relatively simple game that as far as I know is heavily client authoritative so the server is mostly just serving content and telling other clients the result of your actions. In a game like Call of Duty, while they have some form of lag compensation, if you had all the players in your game freeze for 3 seconds while you shoot them the server will disregard your actions as impossible as the players weren't actually there. It would have been better for you to see the players slightly out of sync or have them teleport a short distance by just losing that one update and continuing to get the rest on time.
Sad to see you being downvoted when you're absolutely right. Yes, UDP is better for a twitch game, at the expense of a lot more work. No, unless you're building a AAA mouse-and-keyboard shooter, you probably don't need more than a TCP connection sending data packets back and forth using a somewhat well-thought-out protocol.
I think the biggest mistake is only testing the app on localhost. While real world users can experience up to 150ms latency and fluctuations. It doesn't matter if you use TCP or UDP you still need a strategy for handling different levels of latency. For testing I use netem to add delay ...
The second biggest mistake is trusting the client. People never cheat in online games, right !? smile Network latency is often less then it takes to render, so naive solutions with simple broadcast servers work well until you need to deal with rouge clients using teleport hacks etc.
There are no set rules when making real time distributed and scalable applications like MMO Games. In my experience it's best to start with a naive demo/prototype to see where the bottlenecks are.
I would suggest starting with TCP and then only switching to UDP, or more likely making your own protocol (TCP ontop of UDP smile), when you know the requirements.
