Usually, services provide endpoints with which clients can communicate. In the case of peer-to-peer applications, the applications are, by definition, peers, and so it is not appropriate to differentiate one as the service to which others are clients. Instead, in defining peer nodes in the language of the Windows Communication Foundation Service Model, one represent all the nodes as clients of one another:

<system.serviceModel>
        <client>
                <endpoint
                        name="MyPeerEndpoint"
                        [...]/>
        </client>
</system.serviceModel>

To indicate that a peer node is to use Peer Channel to communicate via Windows Peer-to-Peer Networking, one selects as the binding for the peer node endpoint the predefined NetPeerTcpBinding. As the name of the binding implies, communications via the NetPeerTcpBinding use TCP. The reliance on TCP simply reflects that of Windows Peer-to-Peer Networking.

The NetPeerTcpBinding can be selected in the configuration of an endpoint in the usual way,

<system.serviceModel>
        <client>
                <endpoint
                        name="MyPeerEndpoint"
                        binding="netPeerTcpBinding"
                      [...]/>
        </client>
</system.serviceModel>

although a port must be specified, and that is done through a customization of the binding, rather than via the address:

<system.serviceModel>
        <client>
                <endpoint
                        name="MyPeerEndpoint"
                        binding="netPeerTcpBinding"
                        bindingConfiguration="PeerBinding"
                        [...]/>
        </client>
        <bindings>
          <netPeerTcpBinding>
            <binding
              name="PeerBinding"
              port="8090"
            </binding>
          </netPeerTcpBinding>
        </bindings>
</system.serviceModel>

If it is desirable to authenticate the source of communication, that option can also be selected via a customization of the binding. The source can be authenticated using a password or an X.509 certificate. If a certificate is to be used, it is also necessary to configure a behavior, as shown in Listing 17.1. That behavior must specify the certificate to be used to identify the source of outbound communications, and also specify the store of trusted certificates to be used to authenticate the sources of inbound communications.

<system.serviceModel>
        <client>
                <endpoint
                        name="MyPeerEndpoint"
                        binding="netPeerTcpBinding"
                        bindingConfiguration="PeerBinding"
                        behaviorConfiguration="PeerEndpointBehavior"
                        [...]/>
        </client>
        <bindings>
      <netPeerTcpBinding>
        <binding
          name="PeerBinding"
          port="8090"
        </binding>
      </netPeerTcpBinding>
    </bindings>
    <behaviors>
      <endpointBehaviors>
        <behavior name="PeerEndpointBehavior">
          <clientCredentials>
            <peer>
               <certificate
                                 findValue="CN=FabrikamEnterprises"
                                 storeLocation="LocalMachine" />
               <peerAuthentication
                                 certificateValidationMode="PeerTrust"
                                 trustedStoreLocation="CurrentUser"
                                 revocationMode="NoCheck"  />
            </peer>
          </clientCredentials>
        </behavior>
      </endpointBehaviors>
    </behaviors>
</system.serviceModel>

If the solution is to be used exclusively on machines that have Windows Peer-to-Peer Networking installed, no further configuration of the binding is necessary. However, Windows Peer-to-Peer Networking is not available on the Windows Server operating systems. The primary significance of that is that there will be no implementation of PNRP to supply the physical network addresses of the nodes within a mesh. It is still possible to deploy Peer Channel solutions on Windows Server 2003, but in that case, it is necessary to have the resolution of the physical network addresses of peers done by a peer name resolver.

A peer name resolver is a class that derives from the abstract base System.ServiceModel.PeerResolver. As shown in Listing 17.2, that base class defines a handful of abstract methods. Peer Channel will invoke those methods to add the current peer node to a mesh, and to ascertain the physical addresses of the other nodes in the mesh when the current node is to send outbound messages. One identifies one’s peer name resolver, one’s implementation of System.ServiceModel.PeerResolver through a customization of the NetPeerTcpBinding configuration, as shown in Listing 17.3. There, the custom peer name resolver is identified as the class, MyResolverClass, in the MyResolverAssembly assembly.

public abstract class PeerResolver
{
   public abstract bool CanShareReferrals { get; }

    public virtual void Initialize(
                EndpointAddress address,
                Binding binding,
                ClientCredentials credentials,
                PeerReferralPolicy referralPolicy);
    public abstract object Register(
                string meshId,
                PeerNodeAddress nodeAddress,
                TimeSpan timeout);
    public abstract ReadOnlyCollection<PeerNodeAddress> Resolve(
                string meshId,
                int maxAddresses,
                TimeSpan timeout);
    public abstract void Update(
                object registrationId,
                PeerNodeAddress updatedNodeAddress,
                TimeSpan timeout);
}

<system.serviceModel>
  <client>
    <endpoint
      name="MyPeerEndpoint"
      binding="netPeerTcpBinding"
      bindingConfiguration="PeerBinding"
      [...] />
    <endpoint
      name="CustomPeerResolverEndpoint"
      address="net.tcp://localhost:8089/MyResolverService"
      binding="wsHttpBinding"
      contract="IMyPeerResolverContract"/>
  </client>
  <bindings>
    <netPeerTcpBinding>
      <binding
        name="PeerBinding"
        port="8090">
        <resolver mode="Custom">
          <custom
            resolverType="MyResolverClass,MyResolverAssembly"/>
        </resolver>
      </binding>
    </netPeerTcpBinding>
  </bindings>
</system.serviceModel>

How would a custom peer name resolver accomplish the tasks of adding a node to a mesh, and retrieving the addresses of the peer nodes within a mesh? Typically, it would do so by contacting a peer name resolution service—an otherwise ordinary Windows Communication Foundation service that keeps track of the peer nodes joining the mesh. So, in Listing 17.3, a client endpoint and the peer node endpoint are configured to define how the custom peer name resolver would communicate with the peer name resolution service. Notice that the binding selected for the communication between the custom peer name resolver and the peer name resolution service in that case is the predefined wsHttpBinding. It could be any binding except NetPeerTcpBinding because the communication between the custom peer name resolver and the peer name resolution service is not peer-to-peer communication, but rather the communication of a client with a service. However, an HTTP binding is selected in this case to emphasize that the peer name resolution service does not have to maintain a TCP connection with every peer node. If it did, the resources of the peer name resolution service’s host would restrict the number of peer nodes that could be included in the mesh.

Addresses used for endpoints configured with the NetPeerTcpBinding must have the scheme, net.p2p:

<system.serviceModel>
        <client>
                <endpoint
                        name="MyPeerEndpoint"
                      address="net.p2p://MyMeshIdentifier/MyEndpointName"
                        binding="netPeerTcpBinding"
                      [...]/>
        </client>
</system.serviceModel>

The next segment of the address, MyMeshIdentifier, in this example, is the identifier of the mesh of peers in which the node is to participate. The remainder of the address is the address of the endpoint relative to the base address constituted by the mesh identifier.

With Peer Channel, a message sent by any node in the peer-to-peer mesh is sent asynchronously, and delivered to every other node in the mesh, including itself. Hence, the pattern for the exchange of messages among peer applications via Peer Channel is always asynchronous and bidirectional. That message exchange pattern is represented in code using the Windows Communication Foundation by defining a service contract that identifies itself as its own callback contract:

[ServiceContract(CallbackContract = typeof(IMyContract))]
public interface IMyContract
{
    [OperationContract(IsOneWay = true)]
    void OneMessage(MyDataType data);

    [OperationContract(IsOneWay = true)]
    void AnotherMessage(string otherData);
}

That location signifies that any application sending a message defined by that service contract must also be prepared to receive that message.

Service contracts with callback contracts are referred to as duplex contracts in the language of the Windows Communication Foundation. Windows Communication Foundation clients for sending messages defined by such contracts are derived from System.ServiceModel.DuplexClientBase<T> rather than System.ServiceModel.ClientBase<T>:

public class MyClient : DuplexClientBase<IMyContract>, IMyContract
{
  [...]
}

Figure 17.1 shows the user interface of the teacher’s application. As the pupils start their applications, each pupil’s application transmits the pupil’s name and photograph to the teacher’s application, which displays the photographs in the area at the top. When the teacher sees that all the pupils have started their applications, and are therefore ready to begin the quiz, the teacher clicks on the Start button to transmit the quiz questions to the students. There is a box for text entry along with a Send button for broadcasting announcements to the class. As the students answer the quiz questions, their responses are displayed in the box in the Grading section of the screen. The teacher can scroll backward and forward through the responses that have been received, and indicate, for each response, whether it is correct or incorrect. The teacher can then click the Grade button to send a message to the application of the pupil who submitted the response, indicating whether the pupil’s response was correct.

Figure 17.1. The teacher’s application.

The user interface of the pupils’ application is shown in Figure 17.2. It has an area on the left to display a picture, an area at the top to display an instruction, and a set of radio buttons to show the possible answers, with a button to submit a selected answer. When the teacher has graded a particular answer, a check mark shows up next to the radio buttons if the answer is correct and a cross shows up if the answer is incorrect. There are buttons to navigate back and forth through the questions.

Figure 17.2. The pupil’s application.

Figure 17.3 depicts one possible sequence of messages that could be exchanged. There are really only two rules, though, governing the sequence of messages. The first rule is that the pupils’ application must send the teacher’s application a Join message before the teacher’s application can begin transmitting AddItem messages to the pupils with the quiz questions. The second rule is that the pupils’ application must send a Response message with the answer to a question before the teacher’s application can send a Response message with the teacher’s assessment of the answer.

Figure 17.3. One possible sequence of messages.

Almost all the data exchanged between the teacher’s application and the pupils’ application via these messages is structured:

Only the announcements that the teacher broadcasts to the class during the quiz constitute unstructured data.

To prepare for an exploration of Peer Channel as a way of implementing the classroom quiz solution, follow these steps:

Because Peer Channel is properly used for the exchange of structured data between peers, the first step in constructing a Peer Channel solution is to design the data structures to be exchanged among the peers. The representation of the data to be exchanged in messages via Peer Channel is done in the same way as it usually is with the Windows Communication Foundation—preferably by designing data contracts, or alternatively by designing XML-serializable types.

To see the data structures defined for use with the classroom quiz application, examine the data contracts in the file Quiz.cs of the Teacher project, which is shared with the Child project. They are reproduced in Listing 17.4. These data contracts represent the messages to be exchanged between the teacher’s application and the students’ application.

[DataContract]
public struct QuizResponse
{
    [DataMember]
    public Student Responder;
    [DataMember]
    public QuizItem Item;
    [DataMember]
    public string ResponseText;
    [DataMember]
    public string ResponseIdentifier;
    [DataMember]
    public bool? Correct;
    public bool Submitted;
}
[DataContract]
public struct QuizItem
{
    [DataMember]
    public string Identifier;
    [DataMember]
    public byte[] ItemImage;
    [DataMember]
    public string Text;
    [DataMember]
    public QuizResponse[] Responses;
    public bool Submitted;

    public string ResponseText
    {
        get
        {
            foreach (QuizResponse response in Responses)
            {
                if (response.Submitted)
                {
                    return response.ResponseText;
                }
            }

            return null;
        }
    }

    public bool? Correct
    {
        get
        {
            foreach (QuizResponse response in Responses)
            {
                if (response.Submitted)
                {
                    return response.Correct;
                }
            }
             return null;
        }
    }
}

[DataContract]
public struct Student
{
    [DataMember]
    public string Name;
    [DataMember]
    public byte[] Image;
}

The Student class represents the message that the pupil’s application will send to the teacher’s application to signal that the pupil has started the application. It contains the pupil’s name and photograph.

The QuizItem class represents the message that the teacher’s application will send to the pupils’ application containing a quiz question. The Identifier, ItemImage, Text, and Responses members of that class represent the identifier of the quiz question, the picture to which the question pertains, the instruction, and various possible responses. The Submitted member will be used internally in the pupils’ application to track whether the response to the question that the pupil selected has been submitted to the teacher.

The QuizResponse class represents the message from the pupils’ application to the teacher’s application conveying the pupil’s response, as well as the message from the teacher’s application to the pupils’ application with the teacher’s assessment of the response. The Responder member identifies the pupil who is responding to the question. The Item member indicates which quiz question is being answered. The ResponseText member contains the pupil’s answer. The Correct member contains the teacher’s evaluation of the pupil’s answer. The Submitted member will be used internally in the pupil’s application to track whether the response is the pupil’s chosen response, and by the teacher’s application to track whether the teacher’s assessment of the response has been transmitted to the pupil who submitted it.

Look at the service contracts defined in the code from the Quiz.cs module of the Teacher project:

[ServiceContract(CallbackContract = typeof(IQuizManagement))]
public interface IQuizManagement
{
    [OperationContract(IsOneWay = true)]
    void Join(Student student);

    [OperationContract(IsOneWay = true)]
    void Announce(string announcement);
}


[ServiceContract(CallbackContract = typeof(IQuizQuestion))]
public interface IQuizQuestion
{
    [OperationContract(IsOneWay = true)]
    void AddItem(QuizItem item);
}

[ServiceContract(CallbackContract = typeof(IQuizResponse))]
public interface IQuizResponse
{
    [OperationContract(IsOneWay = true)]
    void SendResponse(QuizResponse response);
}

These service contracts define the messages and the message exchange patterns required for the classroom quiz solution. The messages they define are

Crucially, each service contract identifies itself as its own callback contract, which, as explained already, is a requirement of service contracts used with Peer Channel, signifying that any application sending a message defined by the service contract must also be prepared to receive that message.

Clients for sending messages defined by the service contracts are also in the Quiz.cs file. The code for those clients is shown in Listing 17.5.

public class QuizQuestionClient :
     DuplexClientBase<IQuizQuestion>,
     IQuizQuestion
{
    public QuizQuestionClient(
                InstanceContext callbackInstance,
                string endpointConfigurationName)
        : base(
                        callbackInstance,
                        endpointConfigurationName)
    {
    }

    #region IQuizQuestion Members

    public void AddItem(QuizItem item)
    {
        base.Channel.AddItem(item);
    }

    #endregion
}

public class QuizResponseClient :
     DuplexClientBase<IQuizResponse>,
     IQuizResponse
{
    public QuizResponseClient(
                InstanceContext callbackInstance,
                Binding binding,
                EndpointAddress address)
        : base(
                        callbackInstance,
                        binding, address)
    {
    }

    #region IQuizResponse Members

    public void SendResponse(QuizResponse response)
    {
        base.Channel.SendResponse(response);
    }
    #endregion
}

public class QuizManagementClient :
     DuplexClientBase<IQuizManagement>,
     IQuizManagement
{
    public QuizManagementClient(
                InstanceContext callbackInstance,
                string endpointConfigurationName)
        : base(
                        callbackInstance,
                        endpointConfigurationName)
    {
    }

    #region IQuizManagement Members

    public void Join(Student student)
    {
        base.Channel.Join(student);
    }

    public void Announce(string announcement)
    {
        base.Channel.Announce(announcement);
    }

    #endregion
}

Usually, in building solutions using the Windows Communication Foundation, after one has defined the service contracts—the interfaces that describe how messages are to be exchanged—the next step is to write classes that implement those interfaces. The same procedure applies when using Peer Channel. Usually, though, it is only an application that is to function as a service that will implement a service contract. By contrast, because Peer Channel applications must also be able to receive the messages that they send, all the applications that are to exchange data with one another via Peer Channel implement all the service contracts defining the messages they are to exchange. Follow these steps to examine the implementations of the service contracts:

To see how the predefined NetPeerTcpBinding is used in the classroom quiz application, follow these steps:

it specifies the NetPeerTcpBinding as the binding of the endpoint. The address it provides, net.p2p://Classroom_3A_ManagementMesh/QuizManagement, conforms to the requirement of using the scheme, net.p2p, in the addresses of endpoints associated with the NetPeerTcpBinding. The next portion of the address, Classroom_3A_ManagementMesh, identifies the name of the Windows Peer-to-Peer Networking mesh to which messsages are to be directed and from which messages may be received. The final portion, QuizManagement, is the name of the endpoint relative to the base addresses constituted by the mesh name.

The customization specified for the predefined NetPeerTcpBinding identifies a port as well as a custom peer resolver—the ResolverClient class that is defined in the ResolverClient project. It also indicates that the pupil’s application and the teacher’s application are to authenticate one another’s users by means of a certificate.

<netPeerTcpBinding>
        <binding
                name="PeerBinding"
                port="8090"
                [...]
                <security mode="Transport">
                        <transport credentialType="Certificate"/>
                </security>
                <resolver mode="Custom">
                        <custom
                                resolverType=
"WindowsCommunicationFoundationHandsOn.School.ResolverClient,ResolverClient"/>
                </resolver>
        </binding>
</netPeerTcpBinding>

The behavior identified in the configuration of the endpoint specifies the certificate to use to identify the user, and the certificate store to use in authenticating the senders of inbound messages:

<behaviors>
  <endpointBehaviors>
    <behavior name="PeerEndpointBehavior">
      <clientCredentials>
        <peer>
          <certificate
                        findValue="CN=FabrikamEnterprises"
                        storeLocation="LocalMachine" />
          <peerAuthentication
                        certificateValidationMode="PeerTrust"
                        revocationMode="NoCheck" />
          <messageSenderAuthentication
                        certificateValidationMode="PeerTrust"
            revocationMode="NoCheck" />
        </peer>
      </clientCredentials>
    </behavior>
  </endpointBehaviors>
</behaviors>

A second endpoint is configured to define how the custom peer resolver is to locate and communicate with the peer name resolution service. An HTTP binding is selected in that case, which, of course, matches the choice of binding in the configuration of the peer name resolution service itself—a fact that can be confirmed by examining the App.config file of the custom peer resolver service project.

<endpoint
    name="CustomPeerResolverEndpoint"
    address="http://localhost:8089/School/PeerResolverService"
    binding="wsHttpBinding"
    contract="WindowsCommunicationFoundationHandsOn.School.IPeerResolver">
</endpoint>

Remember that messages sent via Peer Channel are delivered to every node in the mesh. Yet, there might be cases in which one node has a message that is intended for a specific other node rather than for every node in the mesh. The closest one can come to satisfying that requirement with Peer Channel is to create a mesh consisting of those two nodes only. Then messages from either node, in being delivered to every node in the mesh, will be delivered to only two nodes—the sender and the intended recipient.

In the classroom quiz scenario, each pupil’s answers to the quiz questions are meant to be communicated only to the teacher, and the teacher’s evaluation of each pupil’s answers is meant to be communicated only to that pupil. To see how that requirement is satisfied in the classroom quiz application, follow these steps:

Custom peer name resolution is necessary only on operating systems like Windows Server 2003 on which the .NET Framework 3 can be installed, but Windows Peer-to-Peer Networking is not avaiable. To see how custom peer name resolution is accomplished in the classroom quiz application, follow these steps:

Follow these steps to witness Peer Channel at work in the classroom quiz solution: