Team # 7:  JORBA


Michael Seto

Ian Kalinowski

Jeremy Ng

Wee Ming Choon


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





Wee Ming






Game Server





Client Module





Real time analysis





Reliability analysis





Performance analysis





CORBA development






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.



CORBA, Linux/SDL, C/C++


Third-party software, if any (databases):



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


-          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.



-          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.



April 22, 2005

-          Presentation Slides! (Contains graphs of our HP-RT-FT implementation (link here)

-          Or, you can look at the most relevant graph directly. (link here)