[Intervisionary]

I was just wondering if someone could take a look at the diagram I created for a simple multiplayer blackjack game. I'm not sure if the way I've done things is the most efficient, I know it works though.

Basically:

There is a program running on the server, it handles all game logic. It takes input to it from a socket connection and responds through that socket. Periodically it runs a thread that dumps information into the database (so that when the server is shut down, stuff like player's points aren't killed). Similarly, when a player logs in, his/her necessary data is pulled out of the database and into the program.

The client program simply displays game information and takes user input. It sends requests for information and user input to the server using an HTTP form post on a php script on the server.

The PHP script then sends the data through a socket to the server, it takes the response from the socket and submits it back as a form response which the client then interprets.



My question is, is this model at all sustainable for lots and lots of users? The program on the server has O(1) time for all actions, including requests for information and actions.

Attached image(s)

• 

[ButchDean]

I'm not a network programmer, but my immediate concern is the frequency of database accesses, particularly writes. Also the size of the database could be an issue. Any ideas on how you could manage this?

[Intervisionary]

ButchDean, on 02 June 2012 - 08:18 AM, said:

I'm not a network programmer, but my immediate concern is the frequency of database accesses, particularly writes. Also the size of the database could be an issue. Any ideas on how you could manage this?

To prevent an unreasonable amount of database calls would using a container object inside the controller program work? Should I just make it dump non-essential information once every 10 seconds in large bursts to the database?

There is very little time-sensitive information that needs to be stored.

The database is going to get huge though, maybe logish-like information (player moves) should just get dumped to log files?

At the moment any databasing that takes place is threaded, so the server actually responds to the player before it databases the player's move. This works, because all of the game logic, including the player's state (what game they are in, etc), is stored in the java program in RAM.

[ButchDean]

Have you heard of 'race conditions'? You really need to think carefully about the structure of your database and the number of both read and write accesses there are likely to be.