Peer Networking Series - What is PNRP?

Previous posts in this series:

• What is a Peer Network? 
  
• Introduction to the Windows Communication Foundation Peer Channel

I remember once, back during one of the betas that contained WCF/WPF/WF, there was this tiny little nugget thrown in. It was a managed PNRP API that worked with version 2 of PNRP. I got curious, looked around, and tried to figure out just what the heck PNRP was. Turns out, and I've been quoted as saying as much, that PNRP is quite possibly one of the most underrated development features of Windows. It is extremely powerful and has tremendous capacity for enabling collaborative scenarios in your applications and, unfortunately, most people don't even know it exists.

In a true serverless peer network (I've discussed that particular scenario in a previous article in the series), the single most important task for applications on that peer network is the ability to locate and identify peers. This becomes the job of a name resolver - some tool, service, application, magic black box, whatever, that is responsible for being given the name of a peer computer, peer application, or peer service, and returning something that is addressable at the protocol layer (such as an IP address and port number).

DNS has the ability to store and publish service records, and this is actually done quite often. This is how your copy of Outlook automatically locates the nearest exchange server and its how copies of Office Communicator locate the nearest Microsoft Office Communications Server. The problem with DNS is that updates are slow to propogate and if your peer mesh is only concerned with the link-local scope - DNS is absolutely the wrong tool. What is needed is a DNS that is fast, real-time, dynamic, and geared toward the publication and resolution of more than just computer names.

This is where PNRP comes in. PNRP is a distributed, serverless name resolution protocol. It is easy to publish names using PNRP and you don't need a central registration server. Updates made to PNRP names are done and propagated in real-time. PNRP also allows you to name more than computers - the true goal (IMHO) is to name services. The other feature that truly sets it apart is that peer names can be protected. By digitally signing a peer name, you can guarantee that you will be treated as the one true owner of that peer name, and you are the only one who can change the publication of that name. This is huge for when you want to publish names outside the local scope.

PNRP operates in two different clouds. First is the link-local cloud. This is what most of us who have been doing peer programming are used to from a name resolution standpoint. If you publish a name, everybody on the same subnet as you will be able to resolve the name into an address. The global cloud is the Internet at large and basically what this means is that if you publish a service name on this cloud, anyone in the world should be able to use PNRP and quickly resolve that service name to an IP address and port number. 

There are obviously multiple local clouds and there is one global cloud. Here's another key point: PNRP is fully IPv6 natively. If you're using it with IPv4, PNRP is going to use Teredo to upscale your IPv4 address to an IPv6. 

There are a bunch of other points about PNRP that I would love to make but this is really an introductory post so I want to keep the low-level details out of it until I start showing programming samples. 

Some thoughts to chew on until the next post: 

Peer Channel URLs are not the same as PNRP IDs. For example, if I am writing a peer application and I want to be able to send chat messages to all of the people using my accounting package, I might do so on a mesh with the URL of:

net.p2p://myapplication/accounting/chat

If I was using PNRP and I wanted to advertise the fact that my application had a service called chat, I might publish a PNRP name of:

0.accounting_chat

Where 0 is what's called a "classifier". This goes back to the ability to protect peer names. "0." means an unprotected peer name. If the name were digitally signed, the hash would appear before the "." in the peer name. Also remember that you should think of WCF peer mesh names as multicast addresses for application services. Whereas PNRP IDs are discrete names of published services. Multiple applications can host a service with the same peer name (this basically establishes a peer network) and you can use PNRP to resolve the list of endpoints that are currently hosting this service, but locating peers through PNRP is very different than the "flood transmit" model that the WCF peer mesh uses (even though WCF uses PNRP internally... it abstracts this detail away from you, the developer).

So what do people use PNRP for? Pretty much anything. You could use it to communicate with instances of the same application running on a LAN so that they could allow for local peer collaboration. You could use the global mesh so that, if you were to write a game, you could find other people playing your game anywhere in the world and potentially communicate with them directly. The additional info (binary) field that comes with a PNRP service registration could be used to describe that particular instance of the game world such as rules, maximum number of players, the current map being used, etc.

As usual, my new question isn't "Why should I be using peer networking?" ... my question is: "Why the hell does my app NOT use peer networking and how quickly can I upgrade it?"

More to come!

p.s. If you're waiting for me to post about Live Mesh, keep your pants on... I'm waiting for the peer networking series to build up to the introduction of Live Mesh, as I believe Live Mesh is an evolutionary step in the peer networking ecosystem.

tags: peer  peernetworking  pnrp  peerseries  

links: digg this    del.icio.us    technorati    reddit