Maximum Server Load: TCP vs. UDP

I'm making a simple turn-based game for mobile. How many TCP connections can I have on a single cloud VM? Do I need a separate thread for each TCP connection? How many TCP connections can I get per cloud VM assuming that traffic is sparse (1 packet per second) and that game matches are cheap to host (simple turn-based game).

I would like to use TCP for my game protocol, but I know that UDP can be more efficient. For ex. with UDP I can avoid having thousands of TCP connections on the server. I can just handle a steady stream of UDP packets which should be more efficient when there are thousands of players. I would prefer to have a single cloud VM as my server which could scale with millions of mobile downloads.

 

For a turn-based game -- TCP is fine. As far as how many TCP connections can a server handle, that number won't be your bottleneck as I think its something like 64,000 total inbound to a port, depending on your operating system, network card drivers, and kernel configuration.

As for your server, your bottlenecks will be one of the following:
* amount of data coming in from players that must be processed in a single "game loop"
* amount of TOTAL IO (add together network to all users, network to and back from database, and any local disk IO) that the server has to do in a single "game loop"
* amount of data that needs to be put together and sent back to all players during each "game loop"

A turn based game will not exhibit game loop bottlenecks as quickly as real-time multiplayer, as user's aren't expecting 30 - 60 synchronous updates a second from the server.

It is reasonable that for each player's move, you would take data from one player, do the work on the server, and send the results back to every user in the match.

And as for "scaling to million of mobile downloads", I assume you have some kind of business model associated with your game and that you will be making a little bit of money on each of those downloads and players. You will eventually have some server costs no matter your architecture, but a turn-based game will have the lowest cost of all hosted multiplayer game types.

With all that said, there are many ways to keep this free while you develop and grow to hundreds of concurrent users though, so don't be afraid to get started.

 

One issue with UDP specifically you would run into with a high volume of users talking to the same server is NAT translation table timeout. Last time I looked into it, it is common for datacenter routers to be configured for 5 minutes, but home routers come with timeouts set to as low as 10 seconds (though I remember 30-60 being more common). You don't know what an individual home router is configured to, so you have to design for the worst case.

Since UDP is intended so individual packets can be dropped without issue, you'll want to send keep alive packets every 3 seconds or so just to maintain the entry in the router's NAT translation table while tolerating a couple dropped keep alives.

So without sending any game related data at all, with 64,000 users talking to the UDP server it would be processing 21,333 keep alive packets per second. Seems like a huge waste.

It has been a while since I last looked into how TCP handles keeping connections alive, but I know routers have much longer default NAT translation table timeouts for TCP than UDP, so keep alives are probably not even a thing for TCP. (probably worth looking into though when you're talking about this many connections to a single server)

With a turn based game you might be expecting an average of 1 packet per second, but I'm guessing you'd get a flurry of packets when a turn ends, and then a gap while the player is thinking about their move but hasn't made any choice to send yet. So you might end up with a high percentage of your packets the server processes just being these basically useless keep alives. Additionally, the advantage of UDP is in real time games there is a lot of data sent which is outdated as soon as it hits the wire (position updates of a moving object for example), making resend of the same packet not helpful. But in turn based games generally most, if not all, packets are critical. So TCP starts making more sense.

Good luck with your project!