Peer Channel Chat

  • Article

Download sample

The Chat sample demonstrates how to implement a multiparty chat application by using Peer Channel. Messages sent by any instance of a chat application are received by all other instances.

The Chat sample is not based on the concept of client and service. It is a true peer-to-peer application with each instance acting as a peer of other instances. Each instance can send messages to other instances and receive messages from other instances using the IChat duplex contract.

The Chat sample is based on the Self-Host sample. Also, refer to the Getting Started Sample for a high-level overview of Windows Communication Foundation (WCF).

Note

The setup procedure and build instructions for this sample are located at the end of this topic.

Key Concepts:

Peer Channel is a multiparty, peer-to-peer (P2P) communication technology in WCF. It provides a secure and scalable message-based P2P communication channel for application developers. One common example of a multiparty application that can benefit from Peer Channel is a collaborative application, such as chat, where a group of people chat with one other in a peer-to-peer manner without servers. Peer Channel enables P2P collaboration, content distribution, load balancing, and distributed processing for both consumer and enterprise scenarios.

Peer Channel introduces the following new concepts:

  • A mesh is a named collection (an interconnected graph) of peer nodes that can communicate among themselves and that are each identified by a unique mesh ID.

    Note

    Active nodes in the mesh publish their mesh names, so others can find them. A mesh has the following characteristics: It adjusts to changing membership, it has resilient connectivity in an environment in which nodes are constantly joining and leaving the mesh, and it is dynamically optimized based on traffic patterns.

  • A peer node is an endpoint in a mesh. A single application can have multiple peer nodes participating in different meshes.

  • A peer resolver is responsible for resolving a mesh ID to the endpoint addresses of the nodes in the mesh. A peer node uses these addresses to connect other nodes in the mesh. This enables messages to be propagated throughout the mesh.

Chat is a console application. Each instance of a chat application creates a IDuplexChannel with the same endpoint address. Therefore, a message that is sent by one instance of a chat application on its peer channel is received by all other instances (because they are all using the same address).

The chat application defines and implements the IChat duplex contract. The IChat contract allows only one-way operations because the ServiceModel does not support the single-request multiple-response paradigm (in the case of a multiparty channel, a single request that is sent to the mesh can generate multiple responses).

This sample implements a static main function to create a IClientChannel with the IChat duplex contract and using the endpoint that is specified in the configuration file.

All chat instances must use the same endpoint address to ensure that the messages sent by one instance are received by all other instances.

Chat instances in this sample find each other either through a custom resolver or through the default peer resolver (PNRP). Note that PNRP is not available on Windows Server 2003. Therefore, a custom resolver must be used to run this sample on a system running Windows Server 2003. By default, this sample is set up to use a custom resolver. Whether a custom resolver or the default resolver is used is determined by the chat endpoint defined in the following configuration file. To switch to the default peer resolver (PNRP), replace "BindingCustomResolver" with "BindingDefault" under bindingConfiguration in the sample's configuration file.

<!-- chat instance participating in the mesh -->
         <endpoint name="ChatEndpoint"
                   address="net.p2p://chatMesh/ServiceModelSamples/Chat" 
                   binding="netPeerTcpBinding" 
                   bindingConfiguration="BindingCustomResolver" 
                   contract="Microsoft.ServiceModel.Samples.IChat">
         </endpoint>

In order for the Peer Node to communicate with the Peer Channel Custom Peer Resolver service, the client side configuration of the Peer Channel Custom Peer Resolver is defined in the configuration file.

<!-- Client used to communicate with the custom resolver service. -->
<client>
<endpoint configurationName="CustomPeerResolverEndpoint"
address="net.tcp://localhost/ServiceModelsamples/peerResolverService"
    binding="netTcpBinding"
    bindingConfiguration="Binding3"
    contract="Microsoft.ServiceModel.SamplesICustomPeerResolver">
</endpoint>
</client>

The address identifies the address of the resolver service. If the resolver service is running on a remote machine, replace localhost with a qualified domain name.

The sample also demonstrates how to retrieve the peer node from IClientChannel and to register for online and offline events using IOnlineStatus. An online event is initiated when the peer node is connected to at least one other peer node in the mesh. An offline event is initiated when the peer node is no longer connected to any other peer node in the mesh.

Currently, metadata cannot be generated because a Peer Channel is not integrated with the service metadata utility (Svcutil.exe).

When you run the sample, the chat messages sent by a chat instance are displayed in the console windows of other chat instances. Press the Q key followed by ENTER in each console window to shut down the instance.

Note

The sample currently does not handle all possible exceptions that the infrastructure may throw. If you are using these samples in a commercial or production environment, please follow the correct exception handling best practices.

To set up, build, and run the sample

  1. Ensure that you have performed the One-Time Set Up Procedure for the Windows Communication Foundation Samples.

  2. To build the C# or Visual Basic .NET edition of the solution, follow the instructions in Building the Windows Communication Foundation Samples.

  3. To run the sample in a single- or cross-machine configuration, follow the instructions in Running the Windows Communication Foundation Samples.

  4. Additionally, for the chat sample, the following steps apply. Wherever step 3 refers to client and service, those steps apply to separate instances of the sample (because the chat sample does not have the concept of client and service).

  5. If bindingConfiguration is set to BindingDefault, ensure that PNRP is installed and enabled on all machines being used. If bindingConfiguration is set to BindingCustomResolver, make sure that the Custom Resolver service under Chat\<language>\CustomerResolver\bin directory of the Chat project/solution directory is started on all machines being used.

  6. Start as many instances of the application as desired. Begin by entering a nickname which will distinguish messages sent from a particular client instance. Shortly after this name is entered, chat messages can be sent to the mesh. These messages should be echoed to all the other instances with a distinct member name (that is. a message from a client with the same name will not be displayed, and a single client's own message will not be echoed to the console).

© 2007 Microsoft Corporation. All rights reserved.