|
The Comm Manager handles the communication protocol, synchronization mechanism and
messages delivering.
It is a worker thread invoked by the User Interface thread at game start.
Data structures
 | Instance of Client class - Handles all the network messages directed to the client. |
| Instance of Host class - Exists on the host machine only. Handles all the network
messages directed to the host. |
| IDirectPlay class instance. |
| Connection properties flags (state, player's name, statistics etc.) |
Network structure
| The communication is based on DirectPlay objects. Playing over the Internet imposes the
TCP/IP protocol but other transport layers are also supported (Direct-Cable connection,
LAN (IPX/SPX), Modem-to-Modem etc.) |
| A game exists within a single DirectPlay session created by the server. |
| Each player creates a DirectPlay Player object to join the game session. |
| A special DirectPlay player exists, called the "Host".
This player is created by the server machine (by the Host class) and it is used to manage
the game and broadcast messages to the clients. |
| All the clients send their messages to the host and can receive message only from the
host.
This is a typical star configuration.
 | Major advantages of the star configuration:
 | Scalable network, can handle a large number of clients with little degradation. |
| Clients with inferior network capabilities do not dictate the game network performance. |
| Game management is easier - changes in the server machine apply to the entire game. |
|
| Major disadvantages of the star configuration:
| The server machine must be strong enough to handle the computational load and the large
network bandwidth. |
| Implementing a migrating host is more difficult than in other configurations. The server
machine must exist and maintain a reliable network connection during the entire game. |
|
|
| The server machine also has a client instance (a local tank).
This client instance is referred to as the "Judge" as
it is responsible for maintaining the state of game mines and bonuses. |
| Each machine holds a complete list of game objects (within its Game
Manager). The player's tank is referred to as a "local tank"
and the tanks of the other players are referred to as "remote tanks". |
The protocol
| Message structure
Each message has a constant header of 5 bytes:
| Message type - 1 byte. |
| Message time (game time at the server machine) - 4 bytes. |
|
| Handshaking
| Each player that joins the game, receives a special ACK message from the server machine
containing the host player's ID. |
| Each player sends a REQUEST_TANK message specifying the preferred tank color of the
player. |
| In response, the host sends:
| ADD_TANK message - containing the tank ID, position and direction.
This message is also sent to the other existing players notifying a new tank. |
| ADD_BOARD message - containing the board specifications. |
|
| Only after the client received these messages, the game can begin. |
|
| Tank maneuvers
Each player manages its local tank.
When the local tank changes its maneuver, it sends the new maneuver to the host.
The host broadcasts the maneuver change to all the other players.
Each player upon receiving a maneuver set message, passes the maneuver set to the remote
tank object. |
| Time synchronization
The game time is defined as the local time of the host machine. Each client keeps
its local time synchronized with the game time. All the messages sent on the network
(between the host and clients) are having a time stamp with the game time when the message
was constructed. On the host machine the incoming messages are sorted by the time stamp.
On the clients' machines the time stamp is used to calculate the clocks offset between the
local machine and the host machine. The offset is updated on the arrival of every message
using the smoothed average algorithm. When a client sends a
message (always to the host) it put in the time stamp the estimated game time based on its
local time and the clocks offset. A player that can't keep its messages synchronized, i.e.
the host receives the messages with a game time stamp too far in the past, will change its
state from active tank to zombie tank. Zombie tanks can regain their active state if their
network connection is improving for at least some sequential messages. The estimated round
trip from host to each player can be viewed in the 'Server Management' dialog. |
| Game state synchronization
Each player sends its game state every second to the host. The host compares its
local tank (judge) game state with the reported game state. It then updates the reporting
player on all game objects (that need to be updated) other then it's own tank and updates
all the other players on the reporting tanks last position and status changes. Since a
game state may consist of a large number of game objects thus making the game state
message quite large (hundreds of bytes), the message is send condensed - e.g. mines are
reported as a check sum per sector, etc.. |
| Chat messages
Chat messages, just as all other game messages, are sent from each client to the
host. The host dispatches the message to all clients participating in the game session. |
| Disconnection
A player can disconnect the game session in a graceful or an ungraceful way.
Each client is automatically sending a keep-alive message which is handled by the
DirectPlay layer. After a long period of silence, the client will be (ungracefully)
disconnected from the session.
Selecting the stop game option or quitting the game (in game-over mode) will (gracefully)
disconnect the player from the session.
Note: when a player is in the game over mode, it doesn't have a tank anymore but it
still occupies one of the four game players. Thus blocking another player to join the
session. |
|
