Kevin Hoffman's Blog

This is the beginning of a series of blog posts that I plan on doing that will hopefully clear some of the fog surrounding peer networking. At this point in time, creating, consuming, and using peer networks has never been more simple, and there are more efforts on the horizon (topics of future posts) that will bring new meaning to peer networking. If you're as obsessed with networking as I am, this is an incredibly exciting time to be a programmer.

To start the series off, I want to talk about what a peer network really is, and what it means to smart client developers as well as mid-tier developers and even back-end service developers. Disclaimer: I've never been much for buzzwords or terminology, so I might call something by a different name here than you're used to - that's not intentional and its not me being stupid... I just am often out of the "buzzword" or "terminology" loop. I was using Model-View-Controller for months before realizing there was an actual name for that pattern ;)

What is a Peer Network?
Straining really hard to remember back in my days at college... mostly all I can remember are nights spent at the campus center (if you went to UMass, you know the place...) watching Beavis and Butthead and drinking beer... but every once in a while a glimpse of some basic computer science theory returns... like the concept of a fully connected graph. Remember? That's the one where you have a series of nodes and edges where each node has a 1-hop traversal path to every other node in the mesh. A partially connected graph is the same series of nodes, but the edges are more optimally arranged according to some weight or priority, often resulting in multi-hop traversals between any two nodes in the graph.

Peer networks are really just logical graphs of computers, or, in many cases, logical graphs of connected applications. The physical topology of the peer network, means of communication, and weighting of the edges are all implementation-specific details that differ from P2P network to P2P network, but all of them can be reduced down at some point to a drawing containing nodes and edges.

There are many different strategies for arranging peer networks, but the main differentiating factor involves the designation of state servers for central data storage within a peer network and the physical topology of the network. I'll discuss a few (but certainly not all!) of the common topologies of peer networks from an application network topology perspective as opposed to a hardware/physical topology. 

The Hybrid Peer Network
The hybrid peer network is probably the most common form of peer network. Usually it starts out where people have soaring ideals of creating a true serverless peer network and then they realize that such a thing is impractical for what they're doing. So, as a compromise, they stick a central server in the middle of the peer network. Nodes in the mesh still talk to each other as if they were peers when necessary, following the edges as hops and obeying other P2P rules, but when they need central information (which often includes information about who is in the peer network at the time, shared state, central registration, etc) then they talk to the central server. This creates a hybrid network - a network of peers that use traditional client/server patterns for talking to a central registration/state server. You see this kind of network in instant messaging networks all the time - peers talk to each other directly as peers, but the central server is responsible for authentication, authorization, registration, buddy list storage, etc.

Transient State Server Peer Network - Arbitrary / Simple Algorithm
To compensate for some of the issues that people have when building the peer network (such as the infrastructure needs of maintaining a central server and making its location public knowledge and securing it, etc) they often decide to make one of the peers the designated state server for some period of time. Using a simple algorithm, these peer networks often designate the most recently joined node in the mesh as the new state server. The problem with these networks is that the programmer needs to deal with fault tolerance manually - what do you do when the designated peer "server" leaves the mesh? You need to build logic into the system to be aware of that application leaving (either intentionally or through a crash) the mesh and then designating the next state server in line until another peer joins the mesh. 

Transient State Server Peer Network - Election / Complex Algorithm
To compensate for some of the downsides of the previous network arrangement, peer network programmers often create complex election algorithms where the peer itself essentially holds a vote to decide who gets to be the state server. Some advanced implementations do these votes periodically regardless of whether a new node has joined the mesh. This allows the state server to roam, building in a level of fault tolerance. In addition, this kind of topology can support multiple state servers where some are designated backup servers for failover. You can also build enterprise service bus (ESB) style networks where services sit on the peer mesh and respond (idempotently, of course) to requests. These are by far the most complex implementations, but, when implemented properly, these types of networks can become ridiculously powerful and are often the basis for many commercial third-party middleware implementations.

The "Pure" Serverless Peer Network
When I think of a peer network, the first thing that comes to mind is the pure implementation of a network. Peers are in the mesh or they aren't, they have no implicit or explicit ranking or relative importance above and beyond anyone else in the mesh. There is no central state server, the peers do not contain explicit logic to decide upon some node to be a transient state server. If there is shared state in the peer network, it is replicated simply throughout the entire network by pushing data through whatever connection pattern the peer network has already established. If one peer goes down, so what. If all peers go down, so what. The peer mesh can operate with one node or one thousand nodes or ten thousands nodes if necessary - the distributed partial connectivity of the whole thing allows the serverless peer network to scale to enormous sizes without negatively impacting the application using the network. 

Meshes and Mesh Network Optimization
Hopefully you don't have to worry about this. If you are writing an application that takes advantage of a peer network/peer mesh, the details of optimizing the connections between nodes should be abstracted and hidden from you. If you're operating at this low level, you might want to consider using a different peer networking API because you should be concerned with making your application communicate with other instances of itself across a peer network, not about optimizing graph traversal patterns.

What's Next?
In upcoming posts on peer networking, I am going to go into detail about various implementations, including Windows Communication Foundation (WCF)'s Peer Channel, PNRP and its managed API, the differences between what those APIs do and sample applications. I will also eventually end up at a sample application that uses both WCF and PNRP in what I think is an example of a really powerful, really scalable Internet-scoped peer application. 

tags: pnrp  peer  peernetworking  mesh  peerseries  
links: digg this  del.icio.us  technorati  reddit

[This blog appeared originally here and is republished in full with the kind permission of the author, who retains copyright.]