 |
|||||||||
|
|||||||||
|
|
It seems as though whenever I bring up PNRP and its benefits, I am immediately inundated with a list of questions or comments indicating that Microsoft is re-inventing the wheel and that PNRP has already been implemented before in the form of ZeroConf and, more specifically, Apple's implementation of it called Bonjour (formerly known as Rendezvous).
Here's the thing - the two services fix two different problems. The issue arises in that their solution has a small area of overlap and that's what confuses people. Because it is possible to use PNRP's basic implementation in the same way that most people use Bonjour, most people (erroneously so) assume that PNRP is nothing more than a proprietary vendor lock-in version of Bonjour.
First, let's take a look at Bonjour. Bonjour is an implementation of dynamic DNS. In previous posts in this series, I discussed the need for dynamic DNS. Traditional DNS is too slow, too bulky, and isn't really designed for the publication of dynamic services that could go offline at a moment's notice. Services like that might be a printer on your local network, an iTunes shared playlist, or a Windows Media Center device, including services offered on your local network by your Xbox 360. Peer applications traditionally use Bonjour because they need a fast, lightweight way to browse for and publish service advertisements on a local network.
At this point, you're probably thinking, "But wait.. Bonjour that shipped with Leopard can have global scope." And you are quite correct, but remember that Bonjour is still a dynamic DNS protocol. As such, it needs a server for global scope. While you can operate serverless when doing local network multicast, Bonjour still requires you to know about a particular server somewhere "out there" on the intertubes that will host your service publication. Additionally, clients that you want to be able to browse for that record must also know the location of that server. This is perfectly fine if you're a large company and you can easily dedicate a machine in your domain as your Bonjour box, allowing your game or LOB app to find other users globally. But what do you do if you really want a truly serverless peer service publication and location service?
This is where the paths of PNRP and Bonjour diverge. PNRP is, by my definition, a truly peer-to-peer protocol. There is no central state server, no central registration server. If you publish a peer name registration globally through PNRP, you do not need to have a single central server on which to place that record.
The other issue is this: what do you do if you want to make sure that you are the sole owner of that peer name? If you want to make sure that your application is the only application in the world that has the ability to publish service locations for a particular peer name... what do you do? Bonjour doesn't have this built into it. PNRP allows you to digitally sign peer names with your own private key. Anywhere else in the world, any application that attempts to manipulate published name registrations for a secured and signed name - will fail. The only application that can manipulate a signed peer name registration is an application that knows your private key. This is tremendously powerful for peer applications that you want to have a large, global reach but you don't want to deploy all kinds of server infrastructure for maintaining your own registrations like many other applications do.
So it basically comes down to this: Sure, you can use PNRP to do the same thing that Bonjour does, but you can also use PNRP to do quite a few things that Bonjour isn't designed to do. This doesn't mean that Bonjour is bad, because it's actually a kickass piece of technology (you'll know how much I love it if you've seen some of my Cocoa posts in the past). However, if you want to do secured peer name registrations, or serverless global peer name registrations, then PNRP is your tool.
I will be posting more and more about peer networks, peer networking, and eventually heading toward a post about Live Mesh and ecosystems/social networks, so stay tuned!
Ok it looks like I might have been a little inaccurate. It appears as
though the PNRP Global mesh requires a brief interaction with a global
server hosted by Microsoft and also requires fully functioning IPv6 client
support - either natively or through Teredo. So, in short, the main
difference that I can see is that PNRP supports signed peer names, and
Bonjour requires the end user to point at a specific server for global
service publication and PNRP hits a Microsoft server.
Bonjour is multicast DNS - it doesn't need a specific server, as each
client is a peer of another.
Alex, as my blog post said, Bonjour is multicast DNS. The main difference
that I'm seeing between Bonjour and PNRP is that Bonjour is almost
completely limited to the local network. Multicast DNS most certainly will
not escape the local network, and Bonjour's global name registration
requires the end user to go into a configuration panel that you can see on
OS X (no idea where it is on Windows) to add the name of a server on which
to hang registration records. Microsoft has a central server as well, but
PNRP doesn't require end user intervention to manually configure the
infrastructure servers.
Kevin,
That's awesome information. Thanks for clarifying things... Information
that directly compares PNRP and Bonjour is scarce so I appreciate the info!
