The .Net Addict Discusses PNRP, Bonjour and MDNS

  • Artikel

Kevin Hoffman has continued his series about peer-to-peer networking. You can find an index of his posts here: https://dotnetaddict.dotnetdevelopersjournal.com/tags/?/peerseries

After his first post, Kevin received a number of queries asking him to differentiate between PNRP and Bonjour. His article, Peer Networking Series - A Closer Look at PNRP vs. Bonjour/ZeroConf, is definitely worth a read. I’d like to add a little to what Kevin has said by sharing a little more about PNRP.

I won’t spend much time explaining how Bonjour and MDNS work. There are lots of references on the web. The Bonjour Wikipedia article is a good place to start.

Bonjour has several pieces. Kevin’s readers seem to be primarily interested in multicast DNS, which works in a single broadcast domain, and dynamic DNS, which works over the internet. PNRP works both within a broadcast domain, using a link local cloud, and across the internet, using the Global_ cloud.

According to https://www.multicastdns.org/, multicast DNS was designed to resemble the wire protocol and programming interface of DNS as closely as possible. In this respect, the Link-local Multicast Name Resolution (LLMNR) is much closer to Bonjour than PNRP. You can read about LLMNR in the following Cable Guy article from November 2006: https://technet.microsoft.com/en-us/library/bb878128.aspx.

The PNRP protocol and API are very different from DNS, and were designed to provide some extra special features for peer-to-peer application developers. To use these features of PNRP, you’ll have to leave behind at least some of what you know about the DNS protocol and how to write applications that use it. If you’re reading this blog, you’re probably comfortable with the fact that PNRP has its own unique protocol and API, and you’re interested in learning more.

Here are some of the unique features of PNRP (taken from our whitepaper at https://technet.microsoft.com/en-us/library/bb726971.aspx)

PNRP has the following properties:

· Distributed and serverless for incredible scalability and reliability

PNRP is almost entirely serverless (servers are required only for bootstrapping). PNRP easily scales to billions of names. The system is fault tolerant and there are no bottlenecks.

· Effortless name publication without third parties

DNS name publication requires updates to DNS servers. Most people must contact a server administrator. This takes time and incurs costs. PNRP name publication is instantaneous, effortless, and free.

· Real time updates

DNS relies heavily on caching to improve performance. Unfortunately, this means names cannot be reliably updated in real time. PNRP is much more efficient than DNS and can process updates almost instantaneously. Name resolutions will never return stale addresses, making PNRP an excellent solution for finding mobile users.

· Name more than just computers

A PNRP resolution includes an address, port, and possibly an extended payload. With PNRP you can name more than just computers. You can also name services.

· Protected name publication

Names can be published as secured (protected) or unsecured (unprotected) with PNRP. PNRP uses public key cryptography to protect secure peer names against spoofing.

 

I’d like to point out that PNRP has been implemented as a Winsock Name Space Provider (NSP). This means that you can access PNRP through the standard Winsock Service Provider Interface (SPI) functions, making it possible to build an application that has little or no knowledge of the underlying name resolution technologies. In short, you can access PNRP using the same functions that you use to access DNS. You can resolve PNRP names using the getaddrinfo function. I touched on this topic in the post entitled PNRP and pnrp.net. The PNRP API wraps Winsock functions, and simply makes it easier to write PNRP applications.

I hope this post helps clear things up and gets you excited about our more powerful features.

Thanks again Kevin for your excellent articles.

Have fun!

-Tyler

Comments

  • Anonymous
    July 02, 2008
    The comment has been removed