• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Jeanne Boyarsky
  • Ron McLeod
  • Paul Clapham
  • Liutauras Vilda
Sheriffs:
  • paul wheaton
  • Rob Spoor
  • Devaka Cooray
Saloon Keepers:
  • Stephan van Hulst
  • Tim Holloway
  • Carey Brown
  • Frits Walraven
  • Tim Moores
Bartenders:
  • Mikalai Zaikin

How to write a lobby game server

 
Ranch Hand
Posts: 84
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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?

Input is greatly appreciated. Thanks!

Screenshot : http://goo.gl/pYqM3
 
Ranch Hand
Posts: 287
2
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

marwen Bakkar wrote: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?

Input is greatly appreciated. Thanks!

Screenshot : http://goo.gl/pYqM3

You mention lot's of different Java technologies but I'm not sure this is the correct approach. Have you tried writing anything yet just to validate the moves? this is quite complex in itself - castling and en passant are moderately difficult to implement. Then you must decide how to communicate between processes - I'd suggest looking at xboard / winboard protocols. You probably want to store the moves and players in a database with a separate process looking for time outs etc. Then, before producing the front end, I'd have a good long think about whether your software will offer anything different from the various chess servers already on the internet - if it doesn't then you're going to be spending a long time writing something that no-one will use.
 
Marshal
Posts: 28193
95
Eclipse IDE Firefox Browser MySQL Database
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Mich Robinson wrote:I'd have a good long think about whether your software will offer anything different from the various chess servers already on the internet - if it doesn't then you're going to be spending a long time writing something that no-one will use.



I'm sure you're right about chess, but what you say there applies to almost everything that a beginner would produce. (For that matter it applies to a considerable amount of work that advanced programmers would produce, too.) But I would say that this project is a pretty good choice for somebody wanting to learn a variety of techniques and technologies in the (Java) programming world. You've got client-server, you've got GUI, you've got some kind of database and even AI once you get the lower-level stuff under control. That covers a lot of ground.

On the other hand, yeah, it wouldn't hurt to look for features to make your learning project unique in some way. But that's a skill which is somewhat different than the skills required to do the programming.
 
marwen Bakkar
Ranch Hand
Posts: 84
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
I didn't worry about novelty or profitability. All I needed was a hard technical problem to work on. Plus I've found some startup in the gaming industry that does not have chess and they agreed to integrate my work. So they handle the servers and the marketing and I can focus on writing the software. The chess logic is already implemented and bug-free. The server too. The only problem is that now it'll work with a few players but it will not scale. For example, the server maintains a map with player id as key and player socket as value. When a player generates an event (eg writes something in general chat) the server dispatches this to the other players by iterating through the map and locking it to prevent concurrent modification. Let's say there are 300 players online generating various events, the threads on the server will contend too much for the map lock and throughput and service time will suffer. When I read read Java Concurrency in Practice I learned about ConcurrentHashMap but how good it really is? Will all my problems disappear if only I changed my map by a ConcurrentHashMap?

There's also the thread per client problem. I am not sure about this design, I worry 300 threads is too much. There seems to be another model where the server doesn't keep one thread per active connection but instead keeps a list of the connections and then have a single thread poll the connections periodically to see if there's events at the TCP layer pending to be dispatched and notify some listener.This would cure the server from too many threads but at the cost of lower service time..

I could probably figure out how to write the server well if I had a means to test it under moderate and heavy load (200 - 300 connections in one lobby) but I would need actual users. How do I do that?

I think I will write some kind of bot, populate the server with many instances, and see how it behaves. I don't know how viable this is but I'll try. Thoughts please?
 
marwen Bakkar
Ranch Hand
Posts: 84
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Help anyone?
 
With a little knowledge, a cast iron skillet is non-stick and lasts a lifetime.
reply
    Bookmark Topic Watch Topic
  • New Topic