Project Proposal

Baseline Application Description:

We are developing a middleware framework for a game server, supporting a minimum of 50 concurrent two player games per server. The performance of the game server is measured by the number of concurrent games it can support. The real time aspect is measured by the response time for each move.  The fault tolerance and reliability aspect is tested by disconnecting one of the game servers while games are in progress and checking whether the players can still play the same game.  Games will be played via a web server, using Java applets.

Configuration

• Middleware: J2EE
• Operating system supported: Windows XP
• Implementation Language: Java
• Supported Web Browser:  Internet Explorer 5.5 and above
  

• MS SQL Server 2000 or JBoss (TBD)

Reliability Requirements:

• If a middleware server goes down the players will be able to continue playing the same match.

Baseline Application Features:

• Supports two player games (required).  Support for n player games will be added if time permits (optional).
• Non-players can join in as spectators (max 4 spectators).
• Players can send text messages to each other, visible to all of the players and spectators.

Performance Requirements:

• Supports 50 concurrent matches per server
• Supports maximum of 4 spectators per game
• Supports text messages less than 256 characters per message

Real-Time Requirements:

• Response time between moves will be 10 seconds or less as a baseline
• Response time for the text messages will be 10 seconds or less as a baseline

Team Roles:

• Quality Assurance and Workload testing - Lulu
• Fault tolerance - Shailu
• Performance - Randy 
• Real time - Stella
• Database - Justin

Interfaces

The following is the list of interfaces: (click on the file name to view the java doc for each interface)

The server is up and running and waiting for players to log in. When a player does log in, the server makes an entry of this player in its list of available players. The player can view this list on his screen. When another player connects to the server, either of the two players can notify the server that they would like to play against each other. The server sends the request to the other player and once the second player accepts the request, the games begins. The server makes an entry of this game in its list of currently active games. When other users log in to the server, they could similarly start new games. These games are restricted to be two player games. Also, each game could be watched by 4 spectators. When a player makes a move, the client side user interface would be locked and the server would try and notify the second player and the spectators of this move. The server has to periodically save the state of each of the active games in the database. This would help in conditions when the server fails. A player can leave the game any time by pressing the quit button on the client side user interface. When any of the player quits the same, the game is considered as over. The server notifies this to the players and the spectators. Also, the server removes the game from its list of active games. The players are added to the list of currently available games. The spectators are allowed to watch any game as long as there are less than 4 guys watching the game. Any spectator can leave a game at any time. This would not affect the game by any means. When a spectator leaves a game, the server adds the spectator to the list of currently available players.

The home and remote interfaces are ready.

Architecture diagram