Question

I am writing a game server for a turn-based game in Java.
These are the facts:

• The speed of the game is slow, so clients need to send data let’s say every 8 seconds, and that data is most of the time only a small incremental update (a few dozen bytes), aside from situations like join of the game or list available games etc.
• The server must support a large number of players which, let’s say 1000, which play one of a few hundred games
• When player makes a turn, other players in the same game must be notified of the move. The maximum number of players in the game is around 10

First of all, I excluded UDP from my option list as I need a reliable protocol because in rare situations I really need to send some data which cannot fit in one packet and I don’t want to bother with merging packets and similar things, tracking the order of the arrived packages and other low-level stuff.

So the dilemma is whether to use TCP or HTTP.

TCP attempt #1

The connection from the client to the server (and vice-versa) is opened all the time. This way, when a player makes a move, the server can easily notify other players in the game which move was made. The main thing which bothers me with this approach is whether it is advisable or even possible to have as much as 1000 connections and sockets opened all the time?

TCP attempt #2

The alternative which I thought of is, to use to establish a seperate connection/socket on every request from a client. A client would open a connection, send some small data to the server and close that connection. With this approach, I can have a fixed size thread pool of let’s say 10 and process client’s requests in each thread separately so that there is at most 10 connectinos/sockets opened at any time. But there are two things which bothers me with this approach:

1. expensiveness of opening/closing the connection to the client
2. the way of notifying other players in the game, since the connection to them is most probably closed. Each of them should in that case “poll” server for the update let’s say every one second.

What is the cost of establishing a TCP socket/connection? Is this an expensive operation or this is done in only a few ms (or less)?

HTTP

1. Would there be a lot of overhead if
   I would be sending a new GET/POST
   just to send a few bytes?
2. Can I keep 1000 HTTP connections to
   clients simultaneously and then use
   AJAX or similar things to reduce
   overhead? In that case, would 1000
   simultaneous connections pose a
   significant problem regarding
   bandwidth/performance?

I am opened to suggestions/advice of any kind.

Answer 1

Just for your information: HTTP is TCP. A specific protocol that uses TCP, that is. HTTP is based upon TCP, just like TCP is based on IP, etc. So really your choice is between HTTP over TCP or a custom protocol over TCP. You’re right that UDP is a poor match here.

If you’re writing the server yourself, many of the benefits of using HTTP go away. HTTP’s main benefit is that there are highly optimised servers already available so you can use it as a simple and effective RPC system. But if you’re writing the server yourself you’re not likely to reach the efficiency of the likes of Apache so you have to ask why you wouldn’t just pick a simpler protocol to use? Besides, hacking around the pull-only nature of HTTP would seem to be the wrong way to go.

With this in mind, I’d just use a more lightweight protocol over TCP. You get more control over the connections and can notify interested clients of updates without requiring them to poll for changes. You also are able to lose the HTTP request/response overhead which is mostly superfluous in your case. You can instead use a fairly simple bespoke protocol, perhaps based around XML or JSON, or maybe one of the existing RPC methods available.