System Architecture - A Central Server Model

    We have decided to use a central server model, in that we will have a track federate monitoring the events of each race and the cars involved.  Each player will correspond to a player federate.  The federation will be synchronized using a timer federate, which will send a synchronous heartbeat signal out to each of the federates within the system.  The system's protocol will work in a cycle - with each new signal sent out by the timer, the cycle will repeat itself.

Each cycle is as follows:

1.    The TIMER federate sends out a heartbeat clock tick signal to each of the PLAYER federates, every 33 milliseconds**.

**    We have chosen a 33 millisecond clock tick interval in order to ensure smooth graphics.  The minimum acceptable refresh rate for graphics (in order to avoid flickering) is 24 frames per second.  To make sure we meet this standard, we've chosen 30 frames per second.  1 second/30 frames = 33 milliseconds.

2.    Once a PLAYER federate receives a clock tick signal from the TIMER federate, the PLAYER sends its current state (position, speed, etc.) to the TRACK federate.

3.    The TRACK federate waits for updates from all the player federates.

4.    Once the TRACK federate receives updates from all the player federates, it bundles all the information into a packet, and then multicasts this packet back out to all of the player federates.

5.    Each player updates its display (i.e. the position of the other cars on the track) with the information it receives from the TRACK federate.

The details of the order of messages is outlined in the Synchronized Message-Passing Scheme page.

Why a central server, and not a peer-to-peer model?

Comparison of number of messages passed per cycle:

   This graph shows us that once a game has 5 players, our central server architecture will pass far fewer messages per cycle than a peer-to-peer model will.  As more and more players are added, a peer-to-peer model only gets worse.  Why?

  Evaluation of our Central Server architecture
 
For TWO players - each cycle of the message passing protocol involves 7 messages:
  • 3 clocktick() signals - 1 for each player, and 1 for the track
  • 2 updateTrack() signals - 1 for each player
  • 2 updatePlayers() signals - 1 for each player

For THREE players, each cycle of the protocol will involve 10 more messages:

  • 4 clocktick() signals - 1 for each player and 1 for the track
  • 3 updateTrack() signals - 1 for each player
  • 3 updatePlayers() signals - 1 for each player

So this means that for every n players, the system will pass 3n+1 messages.  This is a linear increase in number of messages passed as the number of players increases.

   
  Evaluation of a Peer-to-Peer model
 
     For a peer-to-peer model, players can only communicate among themselves.  Therefore, in order to let the other players know its current state, each player must send an update to every other player but himself.  That is to say that for each player among n players, each player must send n-1 messages per cycle.
                  n(n-1) = n2-n
This means that as the number of players increases, the number of messages passed per cycle increases exponentially.  We can see this in the graph above.
   

What does this all mean?

This means that the Central Server Architecture is a more scalable solution.