Message type in packet vs. connection per message type?

I'm definitely no expert, but depending on how you set things up, you could always have each message include information about what it is that is being sent. That is, so far as I'm aware, the typical approach. Having a unique connection for every possible message type is problematic for several reasons. Consider what would happen if you wanted to make a new message type, as you discover you need a new type to convey a previously unthought of message. You would need to hard code yet another socket, incur all of its overhead, and gain very little by way of benefits. Alternatively, you can just preface your messages with their type (a "header") and never have to worry about expanding the number of sockets. Also, the unique-per-type also means that the server is inundated with unnecessary connections. It has to figure out exactly who is sending what, and that becomes more complex when it has the added need to figure out who is sending what on which socket and how.

I've never seen unique-per-type actually implemented. In my very limited experience, a single socket is typically all that is needed for a client to speak to a server (or two, if you wish to combine multiple protocols like UDP and TCP).

1. Having clients creating a single tcp connection to the server and then so all communication with that conection, but requiring some kind of message type code in the packet
OR:



2. Having clients creating a connection for each message type.

Definitely 1) one connection from each client to the server. For these kind of questions, it is useful to look at how existing games do it. Doing something like 2) would very fast become a scalability and a performance problem.


If you are looking for an existing solution (assuming C++ here), try something like enet, kNet, RakNet, Zoidcom, Lidgren, ... Even if you want to do your own, looking at the existing libraries is strongly recommended, since a "How do they do it?" attitude is one of the best ways to learn.

1. Having clients creating a single tcp connection to the server and then so all communication with that conection, but requiring some kind of message type code in the packet
2. Having clients creating a connection for each message type.

I don't understand why 2 would be useful at all. All it's going to do to you is make messages of different kinds being delivered out of order, which is likely going to introduce significant, hard-to-debug gameplay bugs!

The options for networking are generally:


1. Use UDP, and work around the problem of out-of-order and dropped delivery. Most efficient. Hardest to get right.

2. Use TCP, and wrap each message in a type-and-length prefix. Let the game deal with the fact that the data stream sometimes stutter because of packet loss. Works great for World of Warcraft, for example!

3. Use HTTP, with a request (typically AJAX/AJAJ) per packet. Trust that the browser will use HTTP/1.1 with persistent TCP connections underneath. Very inefficient, but highly compatible with all kinds of networks and devices.


In your case, it sounds as if 2. on this list is the right choice, which is 1. on your list.