8
\$\begingroup\$

So I'm writing a Chess matchmaking system based on a Lobby view with gaming rooms, general chat etc. So far I have a working prototype but I have big doubts regarding some things I did with the server. Writing a gaming lobby server is a new programming experience to me and so I don't have a clear nor precise programming model for it. I also couldn't find a paper that describes how it should work. I ordered "Java Network Programming 3rd edition" from Amazon and still waiting for shipment, hopefully I'll find some useful examples/information in this book.

Meanwhile, I'd like to gather your opinions and see how you would handle some things so I can learn how to write a server correctly. Here are a few questions off the top of my head: (may be more will come)

First, let's define what a server does. It's primary functionality is to hold TCP connections with clients, listen to the events they generate and dispatch them to the other players. But is there more to it than that?

Should I use one thread per client? If so, 300 clients = 300 threads. Isn't that too much? What hardware is needed to support that? And how much bandwidth does a lobby consume then approx?

What kind of data structure should be used to hold the clients' sockets? How do you protect it from concurrent modification (eg. a player enters or exists the lobby) when iterating through it to dispatch an event without hurting throughput? Is ConcurrentHashMap the correct answer here, or are there some techniques I should know?

When a user enters the lobby, what mechanism would you use to transfer the state of the lobby to him? And while this is happening, where do the other events bubble up?

\$\endgroup\$
1
  • \$\begingroup\$ 300 threads is ok on a modern OS, at over 1000 you might want to check out other systems like a not connected one. \$\endgroup\$
    – Valmond
    Oct 31, 2011 at 7:14

2 Answers 2

3
\$\begingroup\$

Model everything as objects. You have the classes chat-room, game-session, player... Don't spawn new threads for new players. Instead try to see every class as a state machine: A player can be connected or disconnected, he has a TcpConnection and a variable specifying how much time he has left to make his move (just as an example).

Then when you have all your objects in an array or something like that, you iterate over it every 10milliseconds (the number is an example too ofcourse) and take appropriate actions.

For example, terminate a game-session if one of the players left the game, send moves from one player to the other player...

For all events that happen in the game you will have to send message trough the network. Create one extra class / enumeration that holds the different message types. If one player makes a move you could send this to the server "move d4 to d5" or something. If you only make a chess game, you can send strings trough the network. For anything more complex I would suggest you send only single bytes.

Typically game packets consist of: the length of the packet, the packet message type / event type (move, player-joined, player-left, ...) and the content (if a player joins, the content would be the name for example)

\$\endgroup\$
0
\$\begingroup\$

To limit the amount of needed threads you should have a look at Java NIO: http://en.wikipedia.org/wiki/New_I/O

\$\endgroup\$

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .