Peer Channel Team Blog

Peer Channel Official Protocol Documentation Link

peerchan — Thu, 01 May 2008 07:13:00 GMT

Check it out here: http://msdn.microsoft.com/en-us/library/cc219453.aspx

New to WCF programming??

peerchan — Fri, 25 Jan 2008 04:21:00 GMT

Check out Clemens Vasters' paper introducing WCF up on http://msdn2.microsoft.com/en-us/library/aa480190.aspx...

Also, some presentations and hands-on labs at http://www.dotnet-university.com/CourseMaterials.aspx

-shalini.

Configuring Peer Channel: With/Without App.config

peerchan — Thu, 24 Jan 2008 01:44:00 GMT

So now that we know what the NetPeerTcpBinding is how you can end up using Peer Channel in your standard WCF application, let's take a look at how to configure peer channel. We follow the standard WCF (.NET really) pattern of allowing configuration through an App.config file for your application or imperatively within the code itself. Which way you choose to go really depends on your needs - if you expect your endpoints/configuration to change a lot and want that aspect flexible etc(eg you use a customResolver for discovery and expect to move it around etc) you'd want to minimize code changes and prefer to change these settings in your config file directly. On the other hand, if you dont really expect to modify your source code that often and dont really want an App.config file, you can opt to just configure everything in code itself. Peer Channel (NetPeerTcpbinding) supports both, to provide a programming model consistent with the rest of WCF.

Using App.config:

The following example attempts to configure a Peer Channel endpoint, with endpointAddress = "net.p2p://ChatMesh/chat"; other endpoint information also is added to the endpoint section of the config file, including fully qualified contract type that is associated with the endpoint, name of config file section that configures the specific binding used, and of course also the type of the binding being used.

All binding configuration (in our case, peer channel (NetPeerTcpbinding)-specific ) settings are in the configuration section corresponding to the one specified in the endpoint section above. (Note: Just in case you are wondering, Visual Studio 8 comes preconfigured with xml information for ServiceModel so intellisense would work and you dont really have to know before hand all the various properties etc.. a quick way to confirm is to check your schema file from the VS install here: C:\Program Files\Microsoft Visual Studio 9.0\Xml\Schemas\DotNetConfig.xsd and search for serviceModel definitions..)

In the bindings section of serviceModel configuration, we specify settings for NetPeerTcpBinding as i show below.

<?xml version="1.0" encoding="utf-8" ?>

<system.serviceModel>

<endpoint name="PeerEndpoint"

address="net.p2p://ChatMesh/chat"

binding="netPeerTcpBinding"

bindingConfiguration="PeerBinding"

contract="Microsoft.ServiceModel.Samples.IChat">

</endpoint>

</client>

</binding>

</netPeerTcpBinding>

</bindings>

</system.serviceModel>

</configuration>

It all comes together when in the code, you specify the endpoint name from the config file to the CreateChannel constructor, like so:

// Construct InstanceContext to handle messages on callback interface.

// An instance of ChatApp is created and passed to the InstanceContext.

InstanceContext site = new InstanceContext(new ChatApp());

// Create the participant with the given endpoint configuration. Each participant opens a duplex channel to the mesh. Participant is an instance of the chat application that has opened a channel to the mesh

ChannelFactory<IChatChannel> factory = new DuplexChannelFactory<IChatChannel>(site, "PeerEndpoint");

Note: Notice that the above example assumes that you are creating a duplexChannel for your application and the client itself is the sender/receiver. You can certainly choose to configure your application such that instead of a duplex channel, you have 1 separate sender and multiple clients (receivers). Check out the Default sample for an idea on how to configure the service/client separately in such a case.

Imperative configuration (Via code and not through the App.config file):

The same configuration above can be achieved through setting the properties on NetPeerTcpbinding programmatically. So programmatically, the settings above would look as under:

InstanceContext site = new InstanceContext(new ChatApp());

NetPeerTcpBinding peerBinding = new NetPeerTcpBinding();

peerBinding.Security.Mode = SecurityMode.None;

ChannelFactory<IChatChannel> factory = new DuplexChannelFactory<IChatChannel>(site, peerBinding);

That's all there is to it :)- (unless of course you would like to use the default custom resolver, in which case check out the scenario sample on msdn on what properties to configure). Hopefully this will help answer some common questions around configuration and also how to convert your app from using App.config to pure code.

As always, feedback welcome and appreciated :)..

-shalini.

Getting started- A Fresh look at Peer Channel (NetPeerTcpBinding)

peerchan — Sat, 15 Dec 2007 03:21:00 GMT

Allright, the general consensus amongst new adopters/potential customers seems to be, that our documentation on msdn seems to be not all that crystal-clear, especially for a new comer, to Peer Channel. And that uptil now, we have been targetting advanced scenarios in our blog - Since it might take a while for us to get stuff added/edited up on msdn, we decided to get some basic stuff up on the blog. So, now shall follow some posts about Peer Channel basics - hopefully, from what i think is scratch :).Feel free to comment on the topics covered and on topics you would like covered here in this section..

Where you will find us:

Peer Channel is enabled by default on Windows Vista - as is all of WCF. So you no longer have to download the runtime components (primarily System.ServiceModel.dll) separately or enable it explicitly.

So all you really need to get started is to add references to System.ServiceModel.dll in your project & you should have access to our classes.

What are we (in terms of WCF):

We are essentially a virtual WCF channel - an abstraction built on top of the WCF TCP channel that provides a means for peer-peer communication, without the application having to worry about it. Most of this functionality is exposed to a WCF application through the NetPeerTcpBinding. It is through the NetPeerTcpBinding that you can configure and query static and instance properties like, IsPnrpAvailable, regular properties that can be set on any WCF binding (eg timeouts), and peer-channel specific properties like Resolver (name resolution), Security options etc..

Default behavior/Properties:

(a) Name Resolution: Our default peer name resolution mechanism uses a resolver based on PNRP the PnrpResolver. This is available on XPSP2 (with Networking pack installed) and by default on Windows Vista. Incase, you dont wish to use Pnrp, you have two other options -

i) DefaultCustomResolver: a WCF TCP service-based name resolver; an implementation we provide out-of-the-box. All you need to do is configure the Resolver property on the NetPeerTcpbinding instance. There are some more configuration steps and our scenario sample on msdn shows how to configure your app to use this resolver.

ii) Custom Resolver - There are times where you might to use your own discovery resolver - for this you can plug in your custom name resolver again by specifying the NetPeerTcpBinding's resolver property with the type of your resolver class. We also ship a custom resolver implementation (again TCP-based) sample for reference.

(b) Security: By default, Peer channel uses password-based authentication for communication amongst peers. So make sure to configure your password on the instance of channelFactory through teh Credential.Peer.MeshPassword property. The certificates used in this authentication are auto-generated and need not be generated/set explicitly, but your application can do so using the Credential.Peer.Certificate property. Our samples show best how this and other security modes can be used with Peer Channel. We'll also cover more on this in a later post..

(c) Listen port: Ports on which your node is listening are auto-generated. So it is really simple for you to run multiple instances of your application on the same machine without any configuration changes. If you would like to explicitly set the port your application should listen on, use the Port property on the netPeerTcpBinding instance.

(d) Listen IPAddress: By default, Peer Channel uses all available IPv4/IPv6 addresses to bind to (including link-local/global IPv6 addresses). However, if you choose, you can make it listen on specific IP addresses using the ListenIPAddress property on binding instance.

Hopefully, I've covered some basics, and this post, coupled with the samples on msdn, should help you get started with writing your first Peer Channel app :). Stay tuned for more fun stuff :)

Limited Message Distribution: A Survey of Flavors

peerchan — Fri, 31 Aug 2007 04:46:00 GMT

One our very, very most frequently asked questions about PeerChannel takes the following form:

"I like the easy way in which I can send messages to everyone one in the mesh, but sometimes, I just want to send a message to [one person, my neighbor, a subset] in the mesh. How do I do that?"

PeerChannel is by design a broadcast mesh, and so is built from the ground up with the intent that messages sent by members of the mesh are received by all members of the mesh. Naturally, this means that PeerChannel is best suited for applications like data broadcast, chat rooms, collaboration, etc. However, in many applications, there will be an occasional need for more limited communication. Although there are variety of ways to limit message distribution, PeerChannel has no built-in method to send a message directly to another member of the mesh, but this is very easy to accomplish. Before we examine options, be sure you ask yourself the following three questions when you discover a scenario in which you need to limit message distribution:

WHO needs to receive this message? Just one neighbor node? A node somewhere else in the mesh? Half the mesh?

HOW OFTEN will this message be sent?

What kind of BANDWIDTH will this message use?

With these three questions answered, let us now discuss the different ways to limit message distribution with PeerChannel:

1) MessagePropagationFilter - This method is used at PeerChannel's transport layer to determine whether or not a message should be deliver to the local node and/or propagated throughout the mesh. See our blog entry for more details. Typically, this should only be used when propagating the message is determined by the actual content of the message, or other very specific scenarios.

2) HopCount - Attribute used to determine how many times a message should be propagated ("hops") before being dropped. Once again, see our blog entry for more details. This is perfect for sending a message to immediate neighbors or neighbors within a few hops.

3) Adding a local filter to the message contract - If the nodes in your mesh each have an individual ID, you can specify a destination ID in the implementation of your message, and have all the nodes ignore messages marked for delivery to another node. This method is perfect for sending to individual members of the mesh, as long as the messages aren't too big or frequent. This is because the mesh will still be used to transport the message, which means that you don't suffer the overhead of setting up a new connection. On the other hand, there will be an efficiency loss as the message is sent many times throughout the entire mesh. Here is a simple example taken from a Chat scenario: I want to send a message to only one person in the mesh, which we will call "whisper". I add a Whisper operation to my contact:

[OperationContract(IsOneWay = true)]
void Whisper(string WhisperMember, ChatMessage msg)

I then implement the Whisper function as follows:

public void Chat(string WhisperMember, ChatMessage msg)
{
    if (WhisperMember != this.member)
    {
        Console.WriteLine("[{0}] {1}", msg.msgSource, msg.msgTxt);
    }
}

4) Setting up a direct connection - You can send connection info over the mesh and then set up a direct connection of your choosing to send/receive messages. This is preferable for long-lasting, high-bandwidth connections between two nodes.

So how do you know which one to choose? It depends on your answers to those three questions. Let us revisit them and see what our answers tell us about which option to use:

WHO:
Complex subset of mesh: MessagePropagationFilter
Neighbors within a certain vicinity: HopCount
Individual node: Local Filter or Direction Connection

HOW OFTEN:
Very frequent: Direct Connection, HopCount, MessagePropagationFilter are preferable
Occasional: Local Filter

BANDWIDTH USE:
High: Direct Connection preferred, less advisable to use MessagePropagationFilter or Local Filter
Low: Any, Direct Connect probably not needed.

Of course, many of these questions do not have black-and-white answers, so each specific application and scenario will be unique. But the concepts remain the same. I hope this helps a little in helping determine which method is best for you. Thanks! -Jonathan

Modifying PeerChat to use Synchronization

peerchan — Fri, 31 Aug 2007 03:27:00 GMT

We return to our favorite application, the Chat room. In this example, we want members who enter and leave the mesh to be able to catch up on what was said while they were gone, so all chat messages will be synchronized throughout the mesh. This will require writing a simple synchronization layer on top of PeerChannel in our PeerChat example.

Note: We are going to start off by NOT enforce ordering of records, but we will discuss that at the end. In a Chat scenario, you would definitely want your synchronized data to be ordered as well.

Let us begin by walking through the 5 steps mentioned in our previous blog entry.

1. Determine the Data Set - Since every member of the mesh will need to view the entire chat log, and since chat logs are not typically too large, we will have every member of the mesh store the entire chat conversation in a local data store called ChatLog.

2. Determine the Data Structure - We will use a typical Dictionary structure for chats. Keys will be chat message IDs (GUIDs), and the records will be a ChatMessage object, containing the message ID, source ID (name of person who sent the chat), and the Chat message itself (a string). Note that this structure itself is not ordered, so we will need to do some additional work later on to satisfy that constraint. Note that we also include a hopcount field, since all sync messages will only be send to immediate neighbors.

[MessageContract]
public class ChatMessage
{
[MessageBodyMember]
public string msgTxt;

[MessageBodyMember]
public Guid msgId;

[MessageBodyMember]
public string msgSource;

[PeerHopCount]
public int hops;

public ChatMessage() { }

    public ChatMessage (Guid id, string text, string source)
    {
        msgId = id;
        msgTxt = text;
        msgSource = source;
        hops = 1;          // Immediate neighbors only
    }
}

3. Sync protocol - We will use a relatively simple, 6-step algorithm as follows:

I) MessageIDRequest: Syncing Node requests a list of message IDs from its immediate neighbors
II) MessageIDResponse: Each neighbor responds with a complete list of message IDs contained in its local data store
III) The syncing Node examines the list of message IDs and generates a list of IDs corresponding to messages missing from its local data store.
IV) MessageContentRequest: The syncing sends its neighbors a content request with a list of message IDs.
V) MessageContentResponse: Each neighbor sends back the complete messages corresponding to the message IDs containing in the content request.
VI) Node A receives the responses containing the messages and adds them to its local data store

This method has two main advantages: the syncing node only receives messages it knows are missing from its local data store, and it can be easily modified such that no two neighbors are required to send back the same messages, reducing duplication. For example, if the syncing node is joining for the first time, and finds out that it is missing messages 1-9, it can request each of its three neighbors to send the content of 3 messages, thereby distributing the sync load and minimized excessive bandwidth use. (This last optimization will be left out of this example for simplicity.)

4. New Message Contract: Below is a interface based off the PeerChat sample in the .NET 3.0 SDK. After the standard Join, Chat, Leave operations, the sync messages definitions follow.

[ServiceContract(Namespace = "http://Microsoft.ServiceModel.Samples", CallbackContract = typeof(IChat))]
public interface IChat
{
[OperationContract(IsOneWay = true)] // Sent when a node joins the mesh
void Join(string member);

[OperationContract(IsOneWay = true)] // Send to indicate that the node is leaving the mesh
void Leave(string member);

[OperationContract(IsOneWay = true)] // A chat message
void Chat(ChatMessage msg);

//**** SYNC OPERATIONS
//******************************

[OperationContract(IsOneWay = true)] // Requests a list of message IDs
void MessageIDRequest();

[OperationContract(IsOneWay = true)] // Responds with a list of message IDs
void MessageIDReply(List<Guid> messageIDs);

[OperationContract(IsOneWay = true)] // Requests the messages corresponding to a list of IDs
void MessageContentRequest(List<Guid> messageIDs);

[OperationContract(IsOneWay = true)] // Responds with a list of messages
void MessageContentReply(List<ChatMessage> messages);
}

5. When to run synchronization: In this simple example, we will assume that no messages are dropped when a node is fully connected to the mesh. However, we will still run synchronization every time a node joins the mesh.

Next, let's go over the implementation of the sync functions. We are introducing a new enumeraion, SyncStatus, to indicate the state of the syncing node. This allows the node to ignore or process the appropriate messages in the process. We add this enumeration as a local member variable named synching, to our node implementation.

public enum SyncStatus
{
    NotSynching,
    IDRequest,
    ContentRequest
}

The following functions are being added to ChatApp, our implementation of IChat. Remember also that the following functions will be executed when the node RECEIVES the given message.

public void MessageIDRequest()
{
    if (this.synching == SyncStatus.NotSynching)
    {
        List<Guid> requestIDs = new List<Guid>(this.chatLog.Keys);
        this.participant.MessageIDReply(requestIDs);
    }
}

Here, we first ensure that we are not current syncing (and therefore have a complete data set). The non-syncing node then create a list of message IDs created from its local data store, chatLog (a Dictionary structure), and sends it back to the mesh.

public void MessageIDReply(List<Guid> messageIDs)
{
    if (this.synching == SyncStatus.IDRequest)
    {
        this.synching = SyncStatus.ContentRequest;
        List<Guid> responseIDs = new List<Guid>();
        foreach (Guid id in messageIDs)
        {
            if (!this.chatLog.ContainsKey(id))
            {
                responseIDs.Add(id);
            }
        }
        if (responseIDs.Count != 0)
        {
            this.participant.MessageContentRequest(responseIDs);
        }
        else
        {
            this.synching = SyncStatus.NotSynching;
        }
    }
}

In this function, the syncing node receives a list of message IDs from a neighbor. It checks its local data store against each message in the list and generates a list of messages missing from its local data store. If no messages are missing, syncing is done. Otherwise, it sends a list of message IDs to its neighbors, requesting the content of those messages. If the node knows the member IDs of its neighbors, it could split up the list between them and send each a unique content request. As a computer science professor would say, "that is left as an excercise for the interested student."

public void MessageContentRequest(List<Guid> messageIDs)
{

    if (this.synching == SyncStatus.NotSynching)
    {
        List<ChatMessage> responseContent = new List<ChatMessage>();
        foreach (Guid id in messageIDs)
        {
            responseContent.Add(this.chatLog[id]);
        }
        if (responseContent.Count != 0)
        {
            this.participant.MessageContentReply(responseContent);
        }
    }
}

Upon receiving the message content request, a non-syncing node creates a list of chat messages corresponding to the message IDs in the list contained in the MessageContentRequest, and sends back the messages to the syncing node.

public void MessageContentReply(List<ChatMessage> messages)
{
    if (this.synching == SyncStatus.ContentRequest)
    {
        foreach (ChatMessage msg in messages)
        {
            this.chatLog.Add(msg.msgId, msg);
        }
        this.synching = SyncStatus.NotSynching;
    }
}

Finally, once the syncing node receives the messages, it adds the messages to its local data store.

Now, all we have left to do with our chat sample is add the following local class varibles to ChatApp:

public Dictionary<Guid, ChatMessage> chatLog;
public SyncStatus synching;

We will also have a new constructor:

public ChatApp(string member)
{
    this.member = member;
    this.chatLog = new Dictionary<Guid, ChatMessage>();
    this.synching = SyncStatus.NotSynching;
}

We also need to log each chat message now. The Chat function in ChatApp will need to the following line of code:

this.chatLog.Add(msg.msgId, msg);

And finally, the node will need to perform the following upon entering the mesh (after calling Join):

instance.synching = SyncStatus.IDRequest;
instance.participant.MessageIDRequest();

At this point, we now have a chat app that contains a synchronized chat log! Displaying the contents of the chat log can be accomplished by enumerating and printing out to the console the content of the ChatLog variable. For example, if "instance" is the name of our ChatApp instance:

ICollection<ChatMessage> messages = instance.chatLog.Values;
foreach (ChatMessage message in messages)
{
Console.WriteLine("=> [" + message.msgSource + "] " + message.msgTxt);
}

And there you have it! With relatively minor changes, our chat application now contains some basic synchronization, useful for those who come late to the chat room and want to catch up on what they missed.

Extra Credit: Ordering Synchronized Messages

In many applications such as chat, it is vital that the order in which messages are created is maintained. Our example neglects this need in exchange for simplicity. However, a real production chat application would definitely need to address this issue. There are a few complications with this, since messages may arrive in different orders to different nodes, so syncing to different nodes will result in different results. For example, if two nodes on either end of a large mesh send a message, nodes in between may differ as to which message arrives first. Here are a couple potential options that we will leave up to you to implement:

- Add timestamps member to each message and attach the current system time to each message before sending. When displaying a message log, the messages can be sorted by timestamp. The difficulty of this approach is that all machines may not be time synchronized, and so inconsistencies may still result.

- Assign a single member of the mesh to determine the definitive ordering of messages. Naturally, this will make things especially difficult if that member goes down, but has the advantage of creating a single, unified ordering across the entire mesh.

- Add to each message the ID of the message that immediately preceeded it. The data store can then link messages together in a hierarchal tree in case two messages arrive with the same previous ID attached. This has the advantage of maintaining order while keeping track of ambiguities, but nevertheless does not resolve the problem.

Best of luck in implmenting your synchronization! -Jonathan

PeerChannel and Synchronization

peerchan — Thu, 30 Aug 2007 22:38:00 GMT

One of our most popular questions has centered around using synchronization with PeerChannel. Although PeerChannel does not include a synchronization layer in box, it is not overly difficult to develop your own synchronization layer on top. Although a complete discussion on distributed synchronization protocols is beyond the scope of a single blog article, I will try to outline some tips and guidance on how a developer might go about adding this component to their PeerChannel-based application. Since PeerChannel already takes care of distributing messages to the entire mesh, synchronization can be summed up in two parts:

A) Ensure that all messages are delivered (i.e. resending dropped messages, a reliability layer)

B) Populating nodes with data when they enter/re-enter the mesh.

Although both parts are essential to ensure good synchronization, the first part alone is sufficient for most purposes. (Also, adding a reliability layer to PeerChannel is another topic in and of itself.) Therefore, we will concentrate on the second part. Here are some basic steps to create your own synchronization layer in PeerChannel:

1. Determine the set of data you want to synchronize. You might want to only synchronize the last 5 minutes of data, or your application might want to synchronize a very large data over a long amount of time. The size and type of this data set will most likely determine whether or not you want each node to have a complete copy of the data, as well as whether or not a centralized solution might be a little more appropriate. (Example: If the data you want to synchronize is several GBs, you'll either want to split that up over many, many nodes, OR have a complete copy of the data set residing on a server).

2. Decide on how each node will store the data you wish to synchronize. One way might be to store data records as entries in a Dictionary structure. The key for each entry in the Dictionary will be a unique ID given to each data record when it sent over the mesh. If the ordering of messages is important, you can use a List structure to organize records, or add ordering to the hash table. (By including a Next field in each record containing the key of the next record, you can walk through all the records in a dictionary in order.)

3. Decide on a synchronization protocol. Once again, the specifc protocol you choose will vary depending on your application. The simple, naive protocol could have just three steps (assumes that all nodes have the complete data set):

I) The node sends a sync request to its immediate neighbors (SyncRequest)
II) The neighbors send a response containing a complete list of data (SyncResponse)
III) The syncing node receives the sync responses and adds the records to its local data store.

Note: Sending a message to a node's immediate neighbors may be accomplished by using the HopCount attribute. For more information on how to use the HopCount attribute, please refer to an earlier entry in this blog.

Most pull-based sync protocols (where the node explicitly requests a sync), generally follow this format to some degree. This particular approach, however, would probably be too inefficient, since all of the node's neighbors will be sending the complete data set. Since a PeerChannel node should have 3 neighbors at all times, that amounts to sending the entire data set 3 times over the network. In addition, the syncing node may already have a part of the data set in the first place, so sending the complete data set would be unnecessary.

4. Add your synchronization protocol messages to your message contract - The simplest way to add your sync messages will be to add them to the contract you are already using to send your application messages over the mesh. You can separate them into their own contract if you like, although this may complicate your code.

5. Decide when to run synchronization. Unless you write your own reliability layer onto PeerChannel, nodes in the mesh will need to periodically run your synchronization protocol, even if they have never left the mesh. This will compensate for the small chance that messages are dropped in the mesh (since PeerChannel doe not offer any reliability guarantees). We have already pointed out that certain sync protocols can be inefficeint with bandwidth, so running synchronization too often can be problematic. However, if synchronization is not run often enough, inconsistency between data sets can persist longer than desired. The exact time interval will need to balance both. And finally, you will need to run synchronization every time a node enters or re-enters the mesh.

At this point, all that is left to do is to implement your sync primitives, add sync calls into your main code, and you're done! Our next entry will walk through modifying the PeerChat example to use synchronization. -Jonathan.

Custom Resolver FAQ: Registration Lifetimes and Refresh

peerchan — Sun, 01 Jul 2007 08:02:00 GMT

As PeerChannel and the .NET Framework continue to gain traction and popularity, we are starting to receive a number of questions about how to use various parts of this exciting technology. Some of our most common questions center around the use of the Custom Resolver Service. Note that a discussion of whether or not to implement a Custom Resolver will be in a upcoming blog entry - we will assume for now that your particular scenario requires the use of a Custom Resolver (for example, if your application runs on Windows Server 2003).

Here are the two main questions I will be answering in this entry:

1) What are Registration Lifetimes? What are they used for?

2) What is the purpose of the Refresh operation? When do I call it?

So let's start with the basics and tackle these questions. A reminder that when we refer to a node, we are talking about a single application endpoint and a mesh refers to a connected groups of nodes.

Registration Record: Each node in the mesh publishes their endpoint information to the resolver service through the Register operation. The resolver service stores this information as a registration record. This registration record contains a unique identifier (RegistrationID), endpoint information (PeerNodeAddress), and expiration time (DateTime).

Why An Expiration Time? Ideally, when each node leaves the mesh, it will call the Unregister operation, which will cause the resolver service to remove the registration entry. However, it may not be unusal for a node to shut down or become inaccessible before calling Unregister. (For example, the node may be connectly wirelessly and go out of range). In this case, the resolver service needs some way of being able to purge stale and invalid registration records. Having an expiration time for each registration record allows the resolver service to indentify these stale records and remove them to keep the registration records clean.

Why Do I Care About Stale Records? There are two reasons why having stale registration records at your resolver service is a bad idea. First, stale records may result in unnessary failed connections. If a node trying to connect to a mesh receives stale connection information from the resolver service, it will take longer, sometimes MUCH longer to connect to the mesh. But it doesn't end there. The second reason why stale records are bad is that they take up memory. Since registrationIDs are typically generated every time a node is created or recreated, it is possible for a node entering and leaving the mesh multiple times to leave several stale registration records. Without an efficient process to remove registrations records, it is inevitable that eventually that the size of the cache used to store registration data will overflow and crash your resolver service. So removing these records is important.

When Do I Remove Stale Records? The default implementation of CustomResolverService class has the CleanupInterval property. This property (a TimeSpan object) tells the resolver service to go through and delete stale records every time CleanupInterval passes. This should be set to a time equal or greater than the RefreshInterval set on the service (more on that later). If you are using the default implementation of the custom resolver service, all you need to do is set this property and you're good to go. Otherwise, if you are implementing your own resolver service, you have a couple choices:

1) Periodic maintenance: Do what we did! Set a timer to go off every so often and go through your data store to delete old records.

2) Passive Deletion: Instead of actively hunting for stale records at intervals, you may want to delete records when your service is already performing another function. This may potentially slow down response time to requests from the resolver clients, but it has the benefits of doing away with a timer and may be more efficient if you don't expect many nodes to leave ungracefully.

How Do I Make Sure Good Records Don't Get Deleted? This is the purpose of the Refresh operation. Nodes publishing information at the resolver service need to call Refresh periodically to ensure that the expiration time on their records is extended. When the resolver service receives a Refresh request, it should look up the record and extend the expiration time. As long as the expiration time stays in the future, the resolver service will not delete the record.

How Do I Know When To Call Refresh? The RegisterResponseInfo and RefreshResponseInfo objects are sent back to the node in response to a Refresh and Register operations, as well as Update (the response to a Update is the same as the response to a Register). These objects contain a TimeSpan property called RegistrationLifetime, which indicates to the node how much time it has before it needs to call Refresh. So if the resolver service responds to a node's Register request with a RegistrationLifetime of 2 minutes, that node needs to call Refresh in under 2 minutes to ensure that the record stays fresh. Of course, the node should keep in mind that there may be a small amount of latency between the node and the resolver service, so it may be a good idea to send a Refresh a tad under the time given by the RegistrationLifetime. Naturally, the resolver service is not forced to delete a registration record the instant it goes stale (this would not scale well), but it must guarantee that registration records are held for the time given by RegistrationLifetime.

Summary:
- Registration records shouldn't last forever - let the default implementation delete them for you, or write your own maintenance function
- To identify stale records, the default implementation marks each record with an expiration time. Custom implementation should do something similar
- In order to avoid having a registration record deleted, a node must call Refresh before the registration record's expiration time.
- The RegistrationLifetime value, sent by the resolver service, tells a node how much time it has to call Refresh before the registration record expires.

And there you have it! Please comment below or contact us if you have any questions about this or any other Custom Resolver Service feature. -Jonathan

Extending the CustomPeerResolverService: LinearResolverService.cs

peerchan — Wed, 20 Jun 2007 16:40:00 GMT

For background information on PeerChannel discovery mechanisms and options please refer to http://msdn2.microsoft.com/en-us/library/aa702771.aspx.

By default, PeerChannel uses the Windows Peer Name Resolution Protocol (PNRP) for discovery of peers and neighbors in the mesh. But we also provide an alternative server-based out-of-the-box discovery service- the CustomPeerResolverService- for situations/platforms where PNRP is not available or feasible. This post talks about how to go about extending default implementation of the custom resolver, for greater control over mesh shaping and discovery.

In general, when a Peer node first starts up, it tries to look up new neighbors by invoking the CustomPeerResolverService.Resolve() method before going ahead and registering itself with the resolver service. To control the shape of your mesh, for example, all you would need is an extension to the resolver service which is similar to default implementation, except for custom Resolve(), Register(), Unregister() methods. In actual programming terms, it means that your customResolverSerivce class implementation would simply inherit from our base implementation and then have scenario-specific customizations and overrides.

Sample User Scenario: I want to create a linear mesh (i.e. every node is connected to exactly one neighbor; the custom name resolver should therefore provide the new requesting node with referrals to only the last node to register with it).

Solution: Attached to the post is a simple extension to the default CustomPeerResolverService with overridden Resolve(), Register(), Unregister() methods.

Configuring your PeerChannel client application to use your custom service: This can be done by configuring the instance of NetPeerTcpBinding in your application like so:

<snip>

NetPeerTcpBinding binding = new NetPeerTcpBinding();

customResolverEpr = "net.tcp://" + customResolverHostName + ":" + CustomResolverServicePort.ToString() + "/DefaultResolverService";

binding.Resolver.Mode = PeerResolverMode.Custom;

binding.Resolver.Custom.Address = new EndpointAddress(customResolverEpr);

binding.Resolver.Custom.Binding = new NetTcpBinding(SecurityMode.None);

</snip>

Whats new in Orcas for PeerChannel : Manual addressing options.

peerchan — Wed, 06 Jun 2007 03:21:00 GMT

V1 of PeerChannel didnt have any support for manual addressing. In fact, the addressing headers are overwritten by the underlying TCP when the PeerChannel passed the message along to the transport. The way PeerChannel preserved the applications's addressing was by making copies and reapplying those to the message before delivering to the application's service runtime on the receiving end.

Some interesting scenarios like Discovery needed a slightly different treatment of addressing headers from PeerChannel. One of the cool scenarios is to layer Discovery over PeerChannel with a CompositeDuplex, where the request is sent over PeerChannel in the outgoing binding, and the responses are handled by 1:1 conections in the incoming binding. pretty cool!

To Support this end-to-end, PeerChannel needed to resurface the application's To header on the receiving side exactly as set by the sender. This To (which could be different from Via) is used by the Discovery layer to route the message to the appropriate application endpoint.

Starting with Orcas, PeerChannel supports this kind of special manual-addressing like semantics. you can open a create host's endpoint with different To and Via values if your application needs this support. On the other hand, on the client side, you can attach a Via behavior (or use the appropriate variation that took To and Via) to open a proxy that stamped To and Via differently.

For example, you could do the following on the client side, to set a different via:

EndpointAddress epaTo = new EndpointAddress(new Uri(to1));

Program context = new Program("0");

DuplexChannelFactory<ITestDuplexChannel> cf = null;

NetPeerTcpBinding binding = new NetPeerTcpBinding();

cf = new DuplexChannelFactory<ITestDuplexChannel>(context, binding, epaTo);

cf.Endpoint.Behaviors.Add(new ClientViaBehavior(via));

cf.Open();

On the service side, you can add a PeerChannel service endpoint to a serivce host and set the ListenUri as follows:

ServiceHost host1 = new ServiceHost(new Program("ServiceHost1"));

ServiceEndpoint sep1 = host1.AddServiceEndpoint(typeof(ITest), binding, epaTo);

sep1.ListenUri = via;

host1.Open();

This new behavior does not require flipping any switches or tweaking settings. It is available straight out-of-the-box.

How many channels can a mesh handle?

peerchan — Tue, 08 May 2007 02:35:00 GMT

It is often asked how many different contracts can a mesh handle. How should one go about deciding howmany channels one can create in an application using the same mesh name. Brief answer is: there is no limit. It depends on the application design and traffic characteristics.

PeerChannel allows creating multiple channels on the same mesh. This is useful when you have multiple contract types that you wish to use for mesh communication. A typical example is a multi media session : one can envision a multimedia application based on peerchannel that uses separate channels for sending audio, slides, video etc,... In this case, different calls to CreateChannel will pass different uris that all reference the same hostname. When the same hostname is used by multiple channel factories, they all use the same PeerNode instance as their transport. This causes the messages sent over different channels to be multiplexed at the peernode layer.

Following factors can influence the design factoring:

Security aspects of different channels. Its easy to decide if all of them have the same requirements. Otherwise, you have to consider factoring the contracts based on this need. Not all channels may need to be secured.

One of the main factors influencing the design is the relative bandwidth requirements of various channels. If there is a channel that needs bigger message size and exchanges messages more frequently than others, then you probably dont want to penalize the quy who is only interested in a small chunk of messages by sending him everything and asking him to forward everything. Remember that in a mesh, everyone receives every message and forwards them on unless restricted by hopcount.

Number of such contracts. It is not a good idea at the same time to make every contract a different mesh. This will bloat up the process with lot of peernodes each trying to build their connections, eating up resources for no good reason.

Consider the overhead of having a peernode:

A peernode consists of the following key parts:

A) PeerNode itself : holds most of the configuration. acts as a container of other key pieces of peer node like, flooder, maintainer, service endpoint etc,... Has no processing overhead by itself - Acts as the public face of the node by turning key events into Offline and Online events.

B) Flooder: this is the part that is responsible for forwarding and delivering messages. A duplicate message is dropped by the Flooder. It also has to maintain certain amount of state about each incoming message, to avoid duplicates and replay attacks. It keeps a cache of message id for each message. This cache is cycle - a message id lives for atmost 5 minutes. A messageId is 16byes (unsecured) or 256bytes in case of authenticated messages. If you are receiving messages at the rate of 500 unsecure messages per sec, then your cache contains rougly 2MB of working size per node. On the other hand, if you are receiving 200 authenticated messages per second, your cache can grow to as much as 15MB.

C) Maintenance: PeerNode has a periodic maintenance component to it. Every minute (or every 32 messages it received), it sends back an ack to its neighbors that contains some key stats : how many messages are exchanged. howmany are useful (non-duplicates, untampered). Every 5 minutes or so (often if you dont have enough connections),the maintainer wakes up and checks the health of neighbor connections - if it has more connections than ideal, it prunes off the less useful of them. If you are less than ideal, it acquires more connections.

D) Service endpoint: This is the component responsible for keeping connections with other peers in the mesh. Main state of this component is the tcp listener and peer proxy connections.

E) Resolver service. Mesh factoring is also influenced by the resolver being used. if you are using PNRP, remember that for each mesh you create, a separate PNRP registration (in each cloud) is made on your behalf. Each registered name probably involves one or more network roundtrips as part of its maintenance. If you are using the custom resolver, your traffic and resource overhead is multiplied by the number of meshes you create. as many registrations, resolves, refresh etc,...

Hope this information is useful when factoring the contracts into service endpoints.

How/where to get the Peer channel samples?

peerchan — Mon, 15 Jan 2007 23:33:00 GMT

We ship a total of 6 samples with the Windows SDK, that are included in the WindowsCommunicationFoundation samples zipped file.

Download locations:

1. RTM Runtime: http://www.microsoft.com/downloads/details.aspx?FamilyId=10CC340B-F857-4A14-83F5-25634C3BF043&displaylang=en

2. RTM Windows SDK: http://www.microsoft.com/downloads/details.aspx?FamilyId=C2B1E300-F358-4523-B479-F53D234CDCCF&displaylang=en

On MSDN:

1. Sample documentation for WCF: http://msdn2.microsoft.com/en-us/library/ms735119.aspx

2. Peer channel sample + documentation on msdn:

The entire list of samples maybe found here: http://msdn2.microsoft.com/en-us/library/ms752266.aspx

Shortcut links to hte individual samples themselves is as under:

(a) Basic Binding samples - Use the Pnrp resolver mode- http://msdn2.microsoft.com/en-us/library/ms735119.aspx

b) Scenario sample -

(i) Chat - Demonstrates Chat using the non-PNRP custom resolver - http://msdn2.microsoft.com/en-us/library/ms751502.aspx

(ii) Custom Resolver (Advanced users) - Demonstrates how to write your own Custom Resolver service and client (instead of using the Pnrp resolver OR the non-Pnrp default resolver service/client that we ship with already). - http://msdn2.microsoft.com/en-us/library/ms751466.aspx

Enjoy!

-Shalini.

Note for Windows XP users: Pnrp v2 upgrade location

peerchan — Tue, 09 Jan 2007 00:44:00 GMT

PNRP resolver-based applications running on XPSP2 with the P2P networking pack installed are running v1 of the PNRP protocol. It is advisable to upgrade to PNRP v2 which can be downloaded as an XP update from http://support.microsoft.com/default.aspx/kb/920342

Significance for Peer channel applications:

- The main advantage of this upgrade is that your apps are interoperable between Windows Vista and XPSP2

-Shalini.

Tip: Automatically deploying P2P (PNRP) components on XPSP2

peerchan — Thu, 04 Jan 2007 02:58:00 GMT

Scenario: Setting up PNRP/P2P Networking components on XPSP2

Tip:

There is a command line option of installing windows components that we sometimes use (Please note that this is a general way of installing windows components by command line and is not exclusive to the P2P components- I would strongly advise you to test this first before using the solution in a commercial application deployment solution- it works fine for some of our automated tests so as far as I know it works well):

1. Save the following text as a .txt file locally to %SystemDrive%

[Components]
Netoc=on
[NetOptionalComponents]
P2P=1

2. Run the following command to install IPv6 on the machine (required for P2P):

netsh int ipv6 install

3. Now execute the following command to install the P2P Networking Pack:

%systemroot%\system32\Sysocmgr.exe /i:%systemroot%\inf\sysoc.inf /u:%SystemDrive%\EnablePnrpOnXPSP2.txt /q /w

This is the best I have so far as automated deployment of the Advanced Networking pack (aka P2P pack) is concerned on Windows XP.

I haven't tried it myself, but I am guessing this could be integrated into the Setup package as well.

Note: Feel free to share your feedback and whether you are able to get this to work for your application deployment.

-Shalini

Happy New Year with WCF RTM

peerchan — Wed, 03 Jan 2007 06:24:00 GMT

Hi,

This is old news now, but the Peer Channel team is happy to announce our RTM version, available as part of the .NET v3.0 WCF components download.

Thanks for trying out our technology and for helping us improve through all these releases..As always questions/feedback welcome.

- The Peer Channel Team.