Scalable State Synchronization using P2P - Part 2 - Running the Test Application

I recommend you read the previous post before this one.

Prerequisites

Enable PNRP. (Windows 7 should already enable it by default.) Look here to learn how to do it.

• I recommended to run the test application and check that at least both instances are well synchronized before implementing your own synchronization business logic. To ensure that it works well and in case there are issues, they are in the implementation level. The application exists in: [Project directory]Roniz.WCF.P2P.ApplicationTester\bin\Debug\Roniz.WCF.P2P.ApplicationTester.exe.

Here is how the test application looks:

Connect to the Mesh

Clicking on "connect" will open the channel and the state can be determined in the diagnostic details section of the window. First, change every WCF channel from "create" -> "opening" -> "opened" and it will insert the own data as it entered in the user details section. Then, when other peers join the mesh, both peers should change the state to "online" and both peers will synchronize their information.

The following screenshot shows the state that occurs when peers A & B connect to the mesh and are in "opened" state. Prior to coming online (connect with at least one other peer), so every peer shows their own data, but is not synchronized yet (peer C is not connected yet).

Next the peers that are in an opened state, automatically begin to try to connect to each other. When a peer is connected to at least one other, its state changed to "online" and the synchronization flow begins.

In the following screenshot, peers A & B are connected and in an online state – so they are synchronized. Peer C is not connected yet.

Updating the Mesh

Clicking on "send update of own details" will update all peers with the information of their own data as it is entered in the user details section.

In the following screenshot, peer D sends an update message with the data "some new data" to peers A, B & C.

Disconnecting from the Mesh

Clicking on disconnect will notify the other online peers and remove the row that represents the peer that disconnected. In this screenshot, peer D disconnected, and the other peers removed his data from their own business logic level.

Now, you can go to the next post that explains how to implement this infrastructure.