To measure the performance of the game in a network, we used the RTT (Round-Trip-Time) measurement.

The RTT is measured by the server machine and is the prime indicator for a slow network connection to one of the players. The host uses the RTT count to decide if a player becomes a zombie or not.

At the end of each conection with a player, the host dumps statistical information to the debug output.

The debug output can be viewed by using debug application (like dbmon) or by running the application inside Visual C++'s environment and watching the debug pane.

To test the game under stress, we used a specialized network congestion utility. This utility can manually block incoming or outgoing network packets for a predefined time (give or take 20 milliseconds).

We used a batch script to perform the tests. We ran the client application under the network delay utility with all the delay combinations between 0 to 1500 milliseconds (with 50 millisecond increases) of both incoming and outgoing packets.

After the results were compiled in a table, we got the following chart:

The red zones in the chart indicate places where the client application became zombie (RTT too big).
The green zones are places where the application played normally.

It is fairly easy to see that the incoming packets delay and the outgoing packets delay sum up to the RTT (give or take network fluctuations).

The mechanisms employed in the game synchronization deliver a relatively smooth game experience under fast to medium networks.
With slow networks (remote Internet connections), the game is choppy and the player's become zmobies a lot.