1

I'm writing a tcp server for an online turn-based game. I've already written a prototype using php sockets, but would like to move to C++. I've been looking at the popular network libraries (ASIO, ACE, POCO, LibEvent), but currently unclear which one would best suit my needs:

1) Connections are persistent (on the order of minutes), and the server must be able to handle 100+ simultaneous connections.

2) Connections must be able to maintain state information (user login info). [my php prototype currently requires each client request to contain the login info]

3) Optionally and preferably multi-threaded, but a single process. Prefer not to have 1 thread per connection, but a fixed number of threads working on all open connections.

I'm leaning towards POCO's TCPServer or Reactor frameworks, but not exactly sure if they meet my requirements. I think the Reactor is single threaded, and the TCPServer enforces 1:1 threading/connection. Am I correct?

In either case case, I'm not exactly sure how to do the most important task of associating login info to a specific connection with connections coming and going at random.

Sam Miller
  • 23,808
  • 4
  • 67
  • 87
Justin
  • 555
  • 4
  • 22

2 Answers2

5

Boost.Asio should meet your requirements. The reactor queue can be serviced by multiple threads. Using asynchronous methods will enable your design of a fixed number of threads servicing all connections.

The tutorials and examples are probably the best place to start if you are unfamiliar with the library.

Sam Miller
  • 23,808
  • 4
  • 67
  • 87
0

You might also take a look at MUSCLE, a multi-user networking library and server I wrote with this sort of application in mind. It's BSD-licensed, handles hundreds of users, and includes a server-side database mechanism for storing and sharing any information you want the clients to know about each other. The server is single-threaded by default, but I haven't found that to be a problem in practice (and it's possible to extend the server to be multithreaded if that turns out to be necessary).

Jeremy Friesner
  • 70,199
  • 15
  • 131
  • 234