 |
|||||||||
|
|||||||||
|
|
This blog is part of a series of posts on peer networking.
To quickly recap from the previous post - a peer network is a logical graph of computers (or applications, depending on your abstraction level) which are connected in some way. In a pure serverless peer network, there is no single designated machine in the network that holds more or less state than any other computer. Hybrid variations of peer networks involve peer communication for some tasks and client/server communication with a state/central server for other tasks.
The Windows Communication Foundation (WCF) peer channel is a means by which .NET developers can create peer applications. Using the simple endpoint-channel paradigm, every application that is a member of the peer network creates an endpoint through which that application communicates with other computers on the mesh.
The interesting thing here is that any given application can communicate with multiple peer meshes at the same time and, depending on what you need to do, you can even have a single application that uses multiple meshes for different things. For example, you might have a data transmission/synchronization mesh and you might have another general-purpose mesh that allows users of your application to chat with each other. The segmentation of traffic over multiple meshes is an architectural decision that is entirely up to the application developer.
So how does it work? Basically you create a WCF service host the same way you would in any other WCF application. The difference is that the service you are hosting is on the WCF peer channel and has an endpoint address that looks something like this:
net.p2p://myapplication/ or net.p2p://myapplication/subcontext
The format of the P2P URL is entirely up to you and totally arbitrary with the exception of the net.p2p:// URL scheme identifier. When your application opens a P2P endpoint on a given mesh (identified using the URLs shown above), it communicates with a Peer Name Resolver and registers the name. If your app is the first endpoint on that mesh, then you're essentially alone in your own world. As other applications are brought up on the same mesh name, they are added to the mesh and become "peers" to your application. When your app invokes a method on the service proxy for that mesh, all the other peers in the mesh (usually, but I'll discuss that later) will have that method invoked on their own endpoints, effectively multicasting method calls across the peer network.
Messages are propagated out to the peer network using the "flood" method. Basically this means that when you call a method, let's say SendChatMessage("Hello Peers!"), that method is converted into a WCF message. That message is then sent to every single one of the nodes that are connected directly to you on the peer channel. These nodes are said to have a "hop count" of 1 and are technically referred to as neighbors (for obvious reasons). Each of these neighbors then takes the message, turns it into a local method call, and has their local SendChatMessage(string msg) method invoked with the appropriate parameters. Additionally, that message is re-sent to each of that neighbor's neighbors, except the neighbor that sent the message. The message is then "flooded" throughout the peer network until everyone in the network has received the message once and only once.
You don't have control over the message distribution mechanism using the WCF peer channel, nor do you have control over who is considered a neighbor and the connection routes among peers. The only thing you can control at the peer protocol level is how far your message can travel. If you set the PeerHopCount attribute on an outbound data message, that hop count will be decremented each time it is retransmitted and messages with a hop count of 0 are not sent further along down the line. This becomes ridiculously useful if you want to send a quick message to local neighbors to get some data without bothering the rest of the peer mesh. Be careful when using this mechanism, however, because you can easily forget that you were distance-limiting your messages and will have a devil of a time trying to track down erratic behavior in your application unless you're careful.
Not only does the WCF peer channel let instances of your application communication with other instances of your application on the same network segment (I believe some routing between segments is possible but I have never tried it so I can't speak to the accuracy of this...), but it allows other applications to communicate with your application as well. Think about this hypothetical scenario - you have a school network. On this school network there are teacher applications and student applications. Teachers can administer tests and publish information for public consumption, which can also be seen by other teachers. Teachers can also publish information on the "teacher only" mesh and share data that way. Students can submit answers to administered tests, etc. Obviously its a contrived sample, but, if you spend a little time thinking, you may come to the same conclusion that I came to a long time ago:
If you are building a new application for Windows XP/Vista, then given how easy it has become to create peer applications using the .NET Framework, you should be asking yourself, "Why is my app not peer enabled?" Obviously there are some good reasons against peer enabling, but... how much happier would your users be if your apps were peer enabled, could communicate with each other and allow users of the same application to collaborate with each other in real-time?
p.s. I know I mentioned peer name resolvers in this blog entry. I plan on discussing this at length in another post. For now, you just need to know that the default name resolver for the WCF peer channel is PNRP (Peer Name Resolution Protocol), and it comes standard with XP SP2+ and Vista.
