In which cases should I close a TCP connection?

Question

I'm currently writing a multi-process network game server (one gatekeeper process which tells players what games are currently running and allows them to create and join games, and a process per game instance).

In which cases it would be useful for the gatekeeper to drop TCP connection to the client, and in which cases it should continue listening? E.g. should the gatekeeper close the connection after the client has successfully joined a game, or retrieved a list of games, or when an error occurs (such as there are no free slots in the game he's trying to join). Or should the connection close on a timeout? Thanks.

Answer 1

The simplest protocols often use a separate connection for every separate transaction. Web browsers, in their simplest mode of operation, would just connect to download a page and then disconnect. But connecting and disconnecting repeatedly to the same server does carry an overhead, so it is also possible to reuse an existing connection.

On the other hand, if there will be long delays between uses of the connection, and there are large numbers of clients, you have to consider the limited number of simultaneous connections that the server can manage. This is where an inactivity timeout may be useful.

Keeping a connection open also allows you to do asynchronous notification from server to client, without the client needing to be outside a firewall. The client connects and then holds the connection, constantly reading from it. The server sends notifications via the connection.

Answer 2

Design the protocol in the simplest way that could possibly work. This probably means closing the connection at the end of a transaction.

If the application ( the gatekeeper for online games) is not performance-critical, or the clients don't need to carry out an extended conversation, you should probably close the socket at the end of the transaction.

The client can always make another one later if it needs to ask another question.

If you need to scale to very high loads (think 10k concurrent sessions per server), consider using UDP, where the server can use a single (or small number of) socket to server a large number of clients.

Answer 3

I work on networked games for a living. All of our connections that are not web or XML requests stay open as long as they are relevant. The client opens the connection to the server and it stays open until one of the following has occured:

1. The client disconnects due to normal operation. In TCP this will eventually kill your connection under MOST situations. However, with certain devices/network connections the disconnect signal won't get sent cleanly so you need backups
2. The client times out. You want to set this fairly high, depending on latency. For something like a gatekeeper server maybe like 5 seconds? Then, you can set it up to do a periodic ping every 2.5 seconds or so, if you're not sure that data will normally be sent often enough to keep the connection alive.
3. The server boots the player. If the player does something invalid like try to cheat, the server will forcibly disconnect the player. It does this by first sending a disconnect packet (with an error message if applicable), and then sometime later killing the connection

I would advise against using UDP for most networked game applications. UDP has a harder time getting through various firewall setups that are in use these days, and if you're doing something vaguely important you'll have to write a packet-guarantee system on top of UDP... which is basically what TCP is. From the old version of our engine to our new one we switched from UDP to TCP.