Team # 7:  JORBA

 

Michael Seto mseto@andrew.cmu.edu

Ian Kalinowski igk@andrew.cmu.edu

Jeremy Ng jwng@andrew.cmu.edu

Wee Ming Choon wmc@andrew.cmu.edu

 

Team Roles (testing, reliability, application, documentation):

	Mike	Jeremy	Ian	Wee Ming
Database				X
Game Server	X	X
Client Module			X
Real time analysis	X	X
Reliability analysis				X
Performance analysis			X	X
CORBA development	X	X

 

Project Title:

Super Borbaman

 

Baseline Application Description:

Fault-Tolerant Real-Time Bomberman-inspired videogame.  Bomberman is an interactive multi-player game where players navigate a grid, and blast their way through fun-filled 2D graphics to combat other opponents.

 

Configuration:

CORBA, Linux/SDL, C/C++

 

Third-party software, if any (databases):

MySQL

 

Baseline Application Features (3-10 high-level bullets):

Required:

-          Allows a client to play with other clients

-          Up to 4 clients (Borbamen) per game

-          A client may only belong to one game

-          A server may support multiple games

-          If a game does not contain the required 4 players, it will block until there are 4 players available.

 

Optional:

-          Login screen and lobby for clients to interact before game starts

-          Rankings for top Borbamen

 

Reliability Requirements (3-10 high-level bullets):

-          Preserves current game state under single server failure

o        Coordinates of players, and player state

o        Bomb locations, timers

o        State of map

o        Score

-          Switch from failed server to another server within 1 second

-          Players who “drop” may rejoin game within 2 seconds

 

Real-Time Requirements (3-10 high-level bullets):

-          Player’s actions affect the server state within 100ms of execution

-          Clients receive server updates concurrently every 50ms

-          Updated game state is saved within database in 25ms

 

Performance Requirements (3-10 high-level bullets):

-          Handles 50 concurrent games (4 Borbamen, 10 sprites)

-          Handles 200 concurrent Borbamen

-          Game begins 1 second after all clients are ready

 

January 28, 2005

-          Architectural diagram (first draft) has been prepared (link here)

-          Interfaces (first draft) has been prepared (link here)

 

February 9, 2005

-          Checkpoint 1 Code is now available. (link here)

o        Allows Client to find Server via a IOR published in a file

o        Client may transmit a single key-press to the server, which will reply to the client with the same information after storing it in the SQL database

o        TODO:             Add naming service

                              Finalize database structure

                              Add missing interfaces / Update current interfaces for the type of data we’ll need to be sending.

 

February 16, 2005

-          Checkpoint 2 Code is now available. (link here) 

o        Updated “Game” interface: Includes new methods – IsGameStarted(), ExitGame()

o        Added new “GameServer” interface: JoinGame()

o        Database structure designed

o        Database is not currently integrated with this code, but we will have it working before the demo

o        Client program functionality added

o        Added basic game logic to the server

 

February 20, 2005

-          Baseline Demo (Checkpoint 3) is now available. (link here). 

o        Usage instructions available in /src/README. Or the (link here)

 

February 28, 2005

-          Fault-tolerant design now available. (link here)

 

March 16, 2005

-          Fault-tolerant baseline now available. (Instructions here) (Source code here)

 

March 25, 2005

-          Fault-tolerant baseline measurements now available.  

o        average fault-free round-trip latency: 14762 us

o        maximum jitter in fault-free round-trip latency: 1045864 us

o        minimum jitter in fault-free round-trip latency: 69 us

o        average failure-induced round-trip latency: 59691 us

o        maximum jitter in failure-induced round-trip latency: 78808 us

o        maximum jitter in failure-induced round-trip latency: 33 us

 

-          Graphs characterizing the RTT for both steady-state and fault-induced scenarios are available. (link here)

 

-          Suggestions to improve Real-Time Determinism:

o        Create script/low priority thread to regularly precache information from the naming service: Having this information handy reduces or removes the latency caused during failover caused by contacting the naming service.

o        Refuse to contact naming service until cache of servers is exhausted: Reduces the probability of having to use nondeterministic network resources.

o        Explore loading balancing: By having numerous servers with Game objects already preallocated, we remove the latency caused by the object creation during failover.

o        Look into CORBA code that creates game objects: Remove nondeterministic elements and optimize it.