• View
• Edit
• History
• Print

NetworkSyncCheck

By Sync Check I refer to the task of checking whether a client is in sync or not. For this we use a protocol in boson that is able to do this task very efficiently. To explain this further let me first torture you with a diagram painted by me:

Sorry about the handwriting, but I am a coder, not an artist

In the image you can see 2 clients, the ADMIN (i.e. the main client who always has the valid data) and the CLIENT (the one we want to know about whether it's still in sync). We start at some moment - an advance call somewhen in the game. A that moment (it must be exactly the same advance call on both clients), we create a SyncCheck log. This is a collection of data describing the current state of the game. Ideally that would be the whole game saved, but that would take too much time (it must be a few ms only, otherwise the player would experience dropouts in the game). Usually this log consists of the most important data in the game - especially the most relevant data (location and health) of as many units as possible. From that SyncLog (we call it L1) we create an MD5 sum. The ADMIN now sends a SyncCheck message to the CLIENT, containing the MD5 sum of L1. When the CLIENT receives that message, it compares the sum to its own MD5 sum and returns a SyncCheckACK message back to the ADMIN. In that message the client tells the ADMIN whether it is still in sync - in this case that's the case.

After sending the message on the CLIENT, it can delete the SyncCheck log L1 again. However the ADMIN must wait with the deletion until it received an ACK from all CLIENTs (it will be used in case of an error).

In the image we have now completed the first SyncCheck. The game continues now and somewhen later we are at another advance call (this is not the next advance call, but sometimes later). Here the same starts again - we create SyncCheck logs (name it L2) and calculate MD5 sums from it. ADMIN sends the sum to the CLIENT and it sends back an SyncCheckACK, indicating that we are still in sync.

Now we are at yet another advance call (A3). It starts as before - we create SyncCheck logs (L3) and send the MD5 sum to the CLIENT. However this time the MD5 sums don't match. The CLIENT recognizes that it is out of sync and then sends a SnyCheckACK message back, indicating that the CLIENT is out of sync. Additionally it sends its whole version of L3 back to the ADMIN. The ADMIN receives the ACK message and can now start to analyze L3. Since it still has its own copy of L3 in memory, it can compare L3 of the CLIENT to its own (valid) L3 and tell the player where the error occurred. After analyzing has been completed, we are done here. We found out that we are out of sync and (probably) even where the error occurred - that's all we wanted to do here.

At this point the ADMIN should start to create a Sync message (see NetworkSync) that is sent to all clients (including the ADMIN). They should load the game from that Sync message, so that they are in sync again.