There’s a little known, but extremely useful feature of PNRP we call extended payload. Every time I explain this feature to someone, their eyes light up. It’s always fun to surprise someone with a tidbit like extended payload, but it disappoints me that more PNRP developers don’t know about this feature already. Time to fix that!
Extended payload allows an application to attach an arbitrary blob of data to a PNRP name at registration time. When a searching application resolves the name, it will download the blob along with the endpoints (addresses and ports) describing the publisher. This is a great way to attach any extra information to your application endpoint that might be needed for the application session. If you were publishing a name identifying a multi-player gaming session, for example, you might include the game level or even level map as extended payload.
It’s important to point out that the extended payload isn’t pushed out into the PNRP cloud. It only lives on the publishers machine, and is only transferred from publisher to resolver at the time of a PNRP name resolution. If your machine is participating in the PNRP cloud by publishing a name, it is helping other nodes to publish and resolve, but it is never hosting extended payload on behalf of another computer. It’s also important to note that the extended payload cannot be tampered with if it is attached to a secure PNRP name, because it is included in a signed message.
If you’re using the native Windows PNRP API, you can register a name with an extended payload using the PeerPnrpRegister function. PeerPnrpRegister takes a PEER_PNRP_REGISTRATION_INFO structure as an argument. The payload member of this structure can be filled out with a blob that will become extended payload. If you’re using System.Net.PeerToPeer, look for the Data property of the PeerNameRegistration and PeerNameRecord classes.
The extended payload cannot exceed 4KB in size, and it’s best to keep your extended payload as small as possible. All PNRP messages are delivered over a UDP transport. This includes the message that carries the extended payload. There is logic in PNRP that breaks up a large extended payload and splits it across multiple UDP packets, allowing you to have a payload greater than 1 MTU. This logic handles message ordering, reassembly and some level of delivery guarantee, but large payloads can hurt performance, especially if the publisher or resolver is on a very lossy network. A PNRP resolve will not complete until the entire extended payload has been transmitted from the publisher to the resolver. If it takes too long to transmit all the pieces of the payload, the whole resolve may fail. If the extended payload is large, the message will be fragmented across multiple UDP packets. A larger number of packets increases the chance that a portion of the message will get lost. Be careful with extended payload, but remember that it’s there if you need it.
Have fun!
-Tyler
In case you haven’t noticed, PNRP is available on Windows Server 2008 (WS08). It exists as an optional component and isn’t installed by default, so you’ll have to walk through some simple steps to get it up and running. Just look in the list of optional components and you’re sure to find PNRP.
I know that some people have hit a snag when trying to setup a Windows Internet Computer Name on a WS08 machine. A WICN can be very useful on some kinds of servers. First of all, it can be a great way to remotely access a service without assigning a DNS name. You can run a webserver out of your house, for example, using a WICN. Second, using WICN is a great way to turn a server machine into a seed node for a private PNRP cloud. See my article entitled Setting up a Private PNRP Global Cloud for more information about this.
If you’re not familiar with Windows Internet Computing Naming, I strongly encourage you to read the article Windows Internet Computer Names available here: http://technet.microsoft.com/en-us/library/bb727045.aspx. A WICN is like a free, secure, always up to date dynamic DNS name.
Here’s the problem and work around:
After punching in one of the NetSH commands to configure your WICN …
netsh p2p pnrp peer set machine publish=start autopublish=enable
or
netsh p2p pnrp peer set machine name="0.insecurename" publish=start autopublish=enable
… you get the message “Element not found.” Don’t fret. All you have to do is manually start the WICN service. It’s called the PNRP Machine Name Publication Service (PNRPAutoReg). The following commands will finish the job:
sc config pnrpautoreg start= auto (set PNRPAutoReg to auto start at boot)
net start pnrpautoreg (start PNRPAutoReg right now)
Have fun!
-Tyler
Kevin Hoffman has continued his series about peer-to-peer networking. You can find an index of his posts here: http://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 http://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: http://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 http://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
We’ve included some really neat performance counters that you can use to monitor PNRP. If you’re an application developer, you might use these performance counters to evaluate what impact your use of PNRP will have on the system as a whole. They're also an interesting debugging aid when things go wrong.
To view these counters, open up perfmon (start > run > perfmon.msc). Click on the “Performance Monitor” choice under “Monitoring Tools” in the left hand pane under the heading “Reliability and Performance.” You should see a graph measuring CPU usage over time. You can add the PNRP counters to this graph by right clicking the image and selecting “Add Counters…” from the menu.
The PNRP performance counters can be found under the heading “Peer Networking Resolution Protocol.” On Vista / WS08 there are five of them. Select the counters you’re interested in, and then click the “Add” button. After clicking “Ok” you should return to the original graph which now includes PNRP metrics.
The five counters are…
Bytes received/sec: the number of bytes received by PNRP in the sampling interval (1 second).
Bytes sent/sec: the number of bytes sent by PNRP in the sampling interval (1 second).
Number of IDs registered: the number of names registered by all processes on the system.
Number of resolves: incremented each time an application initiates a PNRP name resolution.
Stale cache entry hits: incremented each time PNRP attempts to contact an unresponsive node when doing internal cache maintenance or when resolving a name.
It’s important to note that the PNRP performance counters report the cumulative results from all clouds. If you publish a name in both the link local, and Global_ clouds, PNRP will use some on-link bandwidth and some internet bandwidth maintaining the names. If your ISP limits your bandwidth every month, you might be interested in PNRP internet bandwidth usage, but you probably don’t care about the on-link bandwidth use which never makes it to the ISP. Unfortunately, the PNRP performance counters lump it all together.
Have fun!
-Tyler
Hi folks!
I've been quiet for a little while, but I'm coming back at you now with some posts that have been sitting with me for a long time.
Since I spoke with you last, Microsoft released Service Pack 3 for Windows XP. This service pack contains version 2 of the Peer Name Resolution Protocol (PNRP) which is compatible with Windows Vista and Windows Server 2008. PNRP v2.0 was available as a separate download for XP SP2, but now it comes directly with the service pack. You can download XP SP3 from www.microsoft.com/downloads.
Have fun!
-Tyler
Kevin Hoffman is a big fan of the Windows P2P technologies, and he's writing a series of P2P blog posts. Check out his latest post on PNRP ...
http://dotnetaddict.dotnetdevelopersjournal.com/peerseries_pnrp_intro.htm
...and don't miss his article about the WCF Peer Channel ..
http://dotnetaddict.dotnetdevelopersjournal.com/peerseries_wcfpeerchannel.htm
-Tyler
If you’ve poked around the PNRP netsh contexts (and you probably have if you read this blog) I bet you’ve run into the traceroute command. I’m talking about netsh p2p pnrp peer traceroute. The help text will tell you that the command “resolves a peer name with path tracing” but it won’t explain the format of the output, making it very hard to use the command for anything constructive. In this article, I’ll explain the output of the command. Next time, I’ll walk you through some real debugging situations where I helped customers diagnose problems with traceroute.
My Setup
|
On my desktop I register the name 0.tylersReg: |
|
C:\>netsh
netsh>p2p pnrp peer add reg 0.tylersReg Global_
Ok.
|
|
On my laptop I resolve 0.tylersReg using traceroute: |
|
C:\>netsh p2p pnrp peer traceroute 0.tylersReg Global_
Resolve started...
Found:
Addresses: [2001:0000:4136:e38e:3493:3b5a:bc55:afc2]%0:0 tcp
Extended payload (string):
Extended payload (binary):
Resolve Path:
[2001:0000:4136:e38e:38ca:1cbc:e7ec:157a]:3540, (0), (0)
Accepted
[2001:0000:4136:e388:0819:1d1b:b88f:def0]:3540, (4), (47)
Accepted
[2002:ce7e:3b87:0000:0000:0000:ce7e:3b87]:3540, (6), (2000)
Rejected (Unreachable)
[2001:0000:4136:e388:0819:1d1b:b88f:def0]:3540, (4), (31)
Accepted
[2001:0000:4136:e390:3cca:079d:e768:2771]:3540, (5), (1094)
Accepted
[2001:0000:4136:e38c:0851:f227:7c94:6422]:3540, (9), (15)
Accepted
[2001:0000:4136:e38e:3493:3b5a:bc55:afc2]:3540, (129), (47)
Rejected (Dead end)
[2001:0000:4136:e38e:3493:3b5a:bc55:afc2]:3540, (0), (47)
|
Success! I found the name.
The resolve path lists all the nodes PNRP spoke to in finding my target. Each entry in the list represents one node. You can count 8 entries in the list.
I’ll explain what the columns in the list mean by breaking down an example:
[2001:0000:4136:e390:3cca:079d:e768:2771]:3540, (5), (1094)
Accepted
Do you see this entry in the resolve path? It’s the fifth one from the top.
The Fields
1. Service endpoint of the node I’m talking to
[2001:0000:4136:e390:3cca:079d:e768:2771]:3540, (5), (1094)
Accepted
This is the ipv6 address of the node I’m talking to and the port on which his PNRP service is listening. The standard PNRP service port is 3540.
2. Number of bits in common between this node’s ID and the ID I’m searching for
[2001:0000:4136:e390:3cca:079d:e768:2771]:3540, (5), (1094)
Accepted
PNRP IDs are 256 bit numbers, remember? When I search for a name, I first convert that name into a PNRP ID. When I talk to other computers in the cloud, I compare their PNRP IDs with the one I’m looking for. As I go farther along with my search, I expect to hit nodes having IDs numerically close to my target. They should have more and more significant bits in common.
In the example above, my target (0.tylersReg on my desktop) and the current hop share the same 5 most significant bits.
Here’s another example taken from the traceroute.
[2001:0000:4136:e38e:3493:3b5a:bc55:afc2]:3540, (129), (47)
Rejected (Dead end)
This time I matched 129 bits. That’s a lot! In fact, this hop is my target. Remember that a 256 bit PNRP ID has two parts. The most significant 128 bits (called the p2p ID) are a hash of the name. The bottom 128 bits (service location) help us do some locality optimization (among other things). You can think of the the service location bits as being random so it’s only important that we match the top 128 bits.
If a hop in the traceroute has 128 bits or more in common with my target, it is my target.
You’re probably wondering why this hop isn’t the very last one in the list. Go check. It’s the second last hop in the list that matches 129 bits. What gives?
The last two hops in the traceroute are actually the same node. First PNRP finds its target. Then it asks that target to formally prove that it is, in fact, publishing the name it was looking for. This produces an extra hop in the traceroute.
3. Round trip time
[2001:0000:4136:e390:3cca:079d:e768:2771]:3540, (5), (1094)
Accepted
This is the number of milliseconds that it took for me to receive a response to my lookup message. In this example, the round trip time was 1094ms.
PNRP moves on if a hop takes more than 2 seconds, so hops having a round trip time greater than 2000 likely timed out. More on this in a moment …
4. Hop status
[2001:0000:4136:e390:3cca:079d:e768:2771]:3540, (5), (1094)
Accepted
This is how PNRP interprets the hop. There are a number of possibilities.
Accepted: This hop helped me get closer to my target
Rejected: This hop didn’t help and PNRP will ignore it
Rejected (Unreachable): This node didn’t respond in time. It might have powered down, or there might be connectivity problems preventing us from talking.
There are more possibilities, but we’ll discuss these in another blog post.
Let’s take a look at one more hop before we go:
[2002:ce7e:3b87:0000:0000:0000:ce7e:3b87]:3540, (6), (2000)
Rejected (Unreachable)
This hop timed out. See, it took more than 2000ms for the node to get back to me, so PNRP rejected the hop and moved on.
We’ll dig even deeper next time.
Have fun!
-Tyler
Sorry I’ve been gone for a while. I’ve been busy working on some neat new stuff. I can’t wait to tell you about it!
MSDN Magazine has coverage of Peer-to-Peer (P2P) namespace in the upcoming release of the .NET Framework 3.5 (which will ship with Visual Studio® 2008, formerly code-named "Orcas"). Check it out here:
http://msdn.microsoft.com/msdnmag/issues/07/09/Networking/default.aspx
-Tyler
In this installment we’ll talk about failing resolutions, registrations and communication problems between Windows XP and Windows Vista.
Name Resolution Fails
You published a name on one machine, and you can’t resolve it from another
Check cloud status
Working with an unhealthy cloud can make your registrations and resolves fail.
netsh p2p pnrp cloud show list
This command will print out the clouds available on your machine, producing output like the following:
Scope Id Addr State Name
----- ----- ----- ---------------- -----
3 8 1 Active LinkLocal_2001:4898:28:2::/64
1 0 2 Active Global_
Global_ cloud does not exist
When the PNRP service starts up, it creates a cloud only if you have a Global IPv6 address. If the Global_ cloud isn’t present, IPv6 isn’t working on your machine. You may need to debug Teredo/6to4/ISATAP. Refer to some of our earlier blog posts.
Global_ cloud is in the No Net state
Your network cable may have fallen out, your wireless connection went down or your interface was disabled.
Global_ cloud is in the Virtual state
The cloud hasn’t finished initializing. If the Global_ cloud sits in this state, try running netsh p2p pnrp cloud start Global_
Global_ cloud is in the Alone state
Your PNRP instance doesn’t know about any peers. It can’t publish or resolve names in this state. You might have had trouble communicating with the PNRP seed server when bootstrapping.
-Make sure you have a firewall exception for PNRP. By default, PNRP uses UDP port 3540.
-Check your seed server setting using netsh p2p pnrp cloud show seed Global_. By default, Windows Vista is configured to use pnrpv2.ipv6.microsoft.com and pnrpv21.ipv6.microsoft.com.
-Try sending a PNRP ping to the seed server using netsh p2p pnrp diag ping seed Global_
-Try sending an ICMP ping to the seed server using ping-6 pnrpv2.ipv6.microsoft.com
-Test your internet connectivity and make sure you have a usable ipv6 address.
Link Local cloud is in the Alone state
If you’re using PNRP to resolve names published on the same link, you can use the Link Local cloud. If you have only one PNRP node on a link, you can expect your link local cloud to sit in the alone state. If you know that you have neighboring PNRP nodes on your link, there are some things you can do to get your link local cloud working:
- Check the Firewall setting for PNRP port which is UDP 3540.
- Check the Firewall setting for SSDP port which is UDP 1900.
- Check whether the corporate policy allow multicast IPv4 or IPv6 traffic.
- Check whether there is other PNRP nodes in the same Link.
- Check the status of SSDP Service using services.msc.
Test connectivity between the two machines
The last step in a name resolution involves a direct connection between the resolver and the publisher (unlike DNS). If this connection can’t be established, the name resolution will fail. Direct connectivity can fail for a number of reasons. Both peers might be behind symmetric NATs (Teredo won’t work in this case), a firewall might be misconfigured, etc.
You can test connectivity between PNRP nodes with this command:
Netsh p2p pnrp diag ping host [host=]{<ip address> | <host name>} [cloud=]<cloud name>
The output of the command can be a little confusing. Ping host does more than an echo request. When one node PNRP pings another, it actually asks for cache entries.
If the command succeeds, you’ll see the following message:
SOLICIT sent to address: [IP address]:3540.
ADVERTISE returned 5 ID(s) in 0 milliseconds.
… followed by the IDs.
If the command fails, you’ll see the following
Destination did not respond (error 0x80980800).
Make sure the name is really registered
A PNRP name only lasts as long as the process that registered it. This includes registrations made with NetSH. The command netsh p2p pnrp peer add registration registers a name. If you call this from the command line, NetSH starts up, registers a name and immediately exits, tearing down the publication. If you want to publish a name that lasts, call add registration from the p2p peer netsh context and leave the console window open.
Netsh p2p pnrp cloud show names will print out a list of all the names registered on the machine.
You can’t register a name with NetSH, then resolve it with the same NetSH context
The NetSH commands assume that this isn’t an interesting diagnostic. I realize that this is likely your first test when you start playing with PNRP. You open a command prompt, start NetSH, register a name then try and resolve it in the same window. If you want to use a single machine to test PNRP publication and resolution, use two separate consoles and two separate NetSH contexts.
My XP and Vista Machines don’t interact
Your XP machine might be running PNRP v1.0, which is not compatible with PNRP v2.0 on Windows Vista. You can upgrade your XP machine to PNRP v2.0 by installing KB 920342. You can find information about the update and a download link here:
http://support.microsoft.com/default.aspx/kb/920342
The PNRP component may not be enabled on your XP machine. To enable the component:
- Select Add / Remove programs
- Select Add / Remove Windows components
- Select Networking Services and click on details
- ensure that the Peer to peer check box is ticked and then select Okay followed by Next
- The Windows installer will do its thing then you should select Next followed by Finish
Test the install by running netsh p2p pnrp cloud show list from a command prompt. You should see at least a link local and a global PNRP cloud. If you’re missing the Global_ cloud, you’ll need to take some extra steps to get IPv6 working.
My Registration Failed
To register a name, you need to have all the same capabilities needed to resolve a name. Make sure that you’re publishing into an existing, active cloud.
PNRP can be set to resolve only mode using netsh p2p pnrp cloud set pnrpmode RO Global_
A system administrator might set the computers he manages to resolve only. You can check the pnrp mode of each of your clouds using the netsh p2p pnrp cloud show stat command. Look for the Cloud Operational Mode field. It will read “Full Participant” if you’re able to publish names, or “Resolve Only.” You switch between resolve only and full participation with the netsh p2p pnrp cloud set pnrpmode command. You’ll need administrative access.
If you use NetSH to register a name in a resolve only cloud, you’ll get the following error message:
C:\>netsh p2p pnrp peer add registration 0.myName Global_
Cloud is in Search Only mode (error 0x80072cf1).
Thanks!
-Tyler and Pritam
When it comes to troubleshooting networking problems nothing is more trusted then ping. It is probably the first networking utility that everybody masters. When you want know if communication works between point A and B ping is your friend. Often times when working with PNRP I have used ping to make sure that I could ping the seed server. I use ping to ping the Teredo server, the router. I use ping to ping the IPv6 address of other hosts on the network.
However in Vista the windows firewall blocks ICMP traffic by default. A friend of mine called me last week and said that he couldn't ping from one machine to another. He disabled the Windows Firewall service so he knows that is not the problem. In fact that was causing the problem. When you disable that service the operating system thinks something might be wrong and goes into a shields up mode, not letting any traffic through. Also turning off the firewall (either by stopping the service or just turning it off) causes the Teredo client to turn off.
So how do you enable ICMP traffic through the firewall? In XP it was easy. In the firewall user interface there was a checkbox that turns it on and off. In Vista, it is a bit more complicated. There are two ways. The easiest is from the command line using NETSH. From an elevated prompt run:
For ICMPv4:
netsh advfirewall firewall add rule name="ICMPv4 Inbound" dir=in action=allow enable=yes profile=any localip=any remoteip=any protocol=icmpv4:8,any interfacetype=any edge=yes
For ICMPv6:
netsh advfirewall firewall add rule name="ICMPv6 Inbound" dir=in action=allow enable=yes profile=any localip=any remoteip=any protocol=icmpv6:128,any interfacetype=any edge=yes
From the user interface:
- Open the Windows Firewall with Advanced Security user interface. (This can be done by searching for "advanced" on the start menu search.)
- Except the elevated permission.
- Select Inbound Rules on the left side panel
- Select New Rule on the right hand actions panel
- Select a custom rule. Hit next
- Select All programs. Hit next
- Select Protocol Type ICMPv4 (or ICMPv6).
- Select Customize
- Select Specific ICMP Type
- Select Echo Request. Select OK. Select Next
- Select Next to allow all addresses
- Select next to allow this connection.
- Select next to allow all profiles
- Give it a name such as "ICMPv4 Inbound"
- Select Finish
- Right click on the exception that was created and select properties.
- Select the advanced tab
- Click Allow edge traversal (this allows ICMP traffic to go through NATs)
At this point you the firewall should allow ICMP traffic for ping.
-Travis
The other day I read a forum post explaining that it was easy to block PNRP traffic at the edge of the network – just block all traffic headed to pnrp.net. I worry about the user’s motivation for blocking PNRP (peer-to-peer networking and illegal music sharing are not synonymous!) but I feel the need to clear up this misconception and explain *.pnrp.net names. Blocking traffic sent to pnrp.net will NOT stop pnrp.
DNS / Host Name Encoding
If you weren’t already aware, pnrp names can be resolved in your existing Windows applications if they formatted to look like DNS names. We call this DNS encoding. DNS encoding is needed for a number of reasons.
For one thing, pnrp names consist of Unicode characters. Historically, host names could consist of only ASCII letters, numbers and hyphens. To play nicely, we convert PNRP names to punycode during DNS encoding. Punycode makes Unicode strings host name friendly. More information about punycode can be found on the ietf website if you’re interested (http://tools.ietf.org/html/rfc3492).
If you’ve read the pnrp whitepaper, you’ll know that a pnrp name consists of an authority followed by a friendly string known as the classifier. In DNS, it’s usually the other way around. That is, the rightmost portions of the name are considered the most authoritative. To maintain the status quo, we swap the authority and classifier when dns encoding and add on the suffix .pnrp.net. A pnrp name would read classifier.authority.pnrp.net.
We prefix the letter ‘p’ to a converted authority if it does not begin with a letter because a dns label cannot begin with a number. We drop the authority altogether if you’re publishing an unsecured name.
There are a couple of functions for converting between peer name and host name encodings. Our api function PeerNameToPeerHostName converts from pnrp to hostname encoding and PeerHostNameToPeerName does just the opposite. You can also use the netsh p2p pnrp peer show convertedname command.
Demonstration
A demonstration will help you believe me. Let’s use netsh to publish a name in pnrp. We’ll then convert it to host encoding. Finally, we’ll use it in an application: ping!
Register a name
We can use the netsh p2p pnrp peer add registration command to register a name. Be careful though – a pnrp registration only lasts as long as the registering application. If you call netsh p2p pnrp peer add registration from the command line, netsh will start, register the name the immediately exit … unregistering the name! Instead, register the name by following these steps:
1. Start netsh
C:\>netsh
netsh>
2. Switch to the p2p pnrp peer context by typing p2p pnrp peer
netsh>p2p pnrp peer
netsh p2p pnrp peer>
3. Register the name by typing add registration 0.yourName
netsh p2p pnrp peer>add registration 0.tylerTesting
Peer name has been registered in all clouds
Ok.
4. Leave the netsh window open! If you exit netsh, the registration will be torn down.
Convert to host name format
In a separate command prompt, convert to host name encoding using the netsh p2p pnrp peer show convertedname command.
C:\>netsh p2p pnrp peer show convertedname 0.tylerTesting
DNS Name: tyleresting-v2a.p0.pnrp.net
Use your DNS encoded peer name!
The easiest test is ping. Try it!
C:\>ping tyleresting-v2a.p0.pnrp.net
Pinging tyleresting-v2a.p0.pnrp.net [2001:0:4136:e37a:104f:3e94:bc57:5e99] from
2001:0:4136:e37a:104f:3e94:bc57:5e99 with 32 bytes of data:
Reply from 2001:0:4136:e37a:104f:3e94:bc57:5e99: time<1ms
Reply from 2001:0:4136:e37a:104f:3e94:bc57:5e99: time<1ms
Reply from 2001:0:4136:e37a:104f:3e94:bc57:5e99: time<1ms
Reply from 2001:0:4136:e37a:104f:3e94:bc57:5e99: time<1ms
Ping statistics for 2001:0:4136:e37a:104f:3e94:bc57:5e99:
Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
Minimum = 0ms, Maximum = 0ms, Average = 0ms
Under the hood
Finally, we get to the misconception that I set out to clear up. Microsoft is not hosting some kind of DNS to PNRP gateway behind pnrp.net. We’re actually doing a pnrp resolution on your computer when you use a DNS encoded peer name.
Getaddrinfo is the function most applications call to resolve a host name to an ip address. Getaddrinfo is protocol independent and calls into multiple name space providers. DNS and Netbios are two very old examples. PNRP has a namespace provider too. If it sees a request to resolve a name ending in .pnrp.net, it converts the name from host encoding to pnrp encoding, then uses the pnrp service to do a lookup. So you see blocking out connections to .pnrp.net really won’t do much.
As always, email me if you have questions.
Have fun!
Tyler
Tylbart at Microsoft.com
In the next few days, I'd like to post portions of the debugging guide that we've been compiling. First, we need to explain PNRP clouds and cloud states and run through our powerful but cryptic netsh commands. We'll start with clouds.
A PNRP cloud is a group of connected PNRP nodes. By connected, I mean that paths exist between peers such that any node in the cloud can resolve a name published by any other node.
When you start the PNRP service, it joins multiple clouds. Actually, PNRP bootstraps are lazy and will wait for an application to register or resolve a name before spending any bandwidth.
You can list the clouds your machine is participating in with the netsh p2p pnrp cloud show list command. Here’s an example from my computer:
Scope Id Addr State Name
----- ----- ----- ---------------- -----
3 8 1 Active LinkLocal_2001:4898:28:2::/64
1 0 2 Active Global_
PNRP clouds can be classified by the ipv6 scope that they operate on. Your machine will join clouds in the global, link local and site local scopes. The site local scope has been deprecated, so it’s unlikely you’ll encounter it. We won’t talk about it further.
In the listing above, the scope heading refers to the ipv6 scope of the cloud. Global (1), Site Local (2) or Link Local (3) are all valid possibilities.
The Link Local Scope
PNRP will join a link local cloud for every link local address on your machine. Here’s the output of netsh p2p pnrp cloud show list on a machine with two network cards:
netsh p2p pnrp cloud>show list
Scope Id Addr State Name
----- ----- ----- ------- -----
3 8 1 Active LinkLocal_{1FFC205C-6D0D-43A0-B471-59E9FE0CFF}
3 12 1 Active LinkLocal_2001:4898:28:2::/64
1 0 4 Active Global_
Note the naming scheme. PNRP names the link local cloud using the prefix of the Global address assigned to the interface. If you have two interfaces, and they share a Global prefix, PNRP will name the second link local cloud with a GUID.
The Global Scope
PNRP will join the Global_ cloud if you have a global ipv6 address. If you don’t have a global IPv6 address, the Global_ cloud won’t appear. Here’s the output of netsh p2p pnrp cloud show list on a machine without global connectivity
netsh p2p pnrp cloud>show list
Scope Id Addr State Name
----- ----- ----- ---------------- -----
3 8 1 Active LinkLocal_ff00::%8/8
A PNRP node can only join one global cloud at a time. If you’re interested in running a private PNRP cloud, you can set up your own seed node and configure your clients to bootstrap from it. If you do this, your clients won’t be able to resolve names in the global cloud hosted by Microsoft. Be careful!
Cloud States
Active
The node is connected and has neighbors. You can publish and resolve names. Excepting a few very strange situations, an active cloud is a healthy cloud.
Alone
You don’t have any neighbors, so your publications won’t be reachable and you won’t be able to resolve peers in this cloud. It can be perfectly normal for your link local clouds to be alone. There might not be any other PNRP nodes on your link.
Underlying network problems can prevent your clouds from going active. If you’re alone in a cloud, but don’t think you should be, the cloud probably failed to bootstrap correctly. If your Global_ cloud is in the alone state, you’re likely not able to communicate with the seed server. Your firewall might be misconfigured or your packets might be filtered upstream.
If you’re alone in a link local cloud you might have difficulty communicating with computers nearby. PNRP uses the simple service discovery protocol (SSDP) to find neighboring on-link nodes. If SSDP is disabled on your system, or blocked by the firewall, your link local clouds will not bootstrap correctly.
Virtual
We mentioned earlier that PNRP cloud bootstrapping is a lazy operation. A PNRP cloud that has been created, but not used, will be in the virtual state.
As a further optimization, PNRP suspends itself after fifteen minutes of inactivity. If you don’t have a name published and you aren’t resolving any names you can expect to find your clouds in the virtual state.
No Net
If you pull the wire or wander out of your hotspot, your clouds will switch to the no net state.
Synchronizing
Your cloud is in the process of bootstrapping. The bootstrap operation is pretty quick for both link local and global clouds. You have to be sneaky to catch your cloud synchronizing.
Questions about PNRP clouds? Ask us!
Thanks!
Tyler
tylbart at microsoft.com
Would you like to know how our customers are using peer-to-peer? We’re writing case studies. The first is available now!
90 Degree Software besides using various parts of .Net 3.0 leveraged the peer channel, PNRP and IPv6.
Here’s a quote that makes me feel warm and fuzzy:
"Using peer-to-peer technologies in Windows Communication Foundation was easy and enabled us to meet our business needs securely while lowering deployment costs for our customers."
Roger Sanborn, Chief Technology Officer, 90 Degree Software
Abstract: 90 Degree Software is dedicated to revolutionizing the reporting software industry. To that end, the company wanted to create a solution that simplifies the report-building process so that businesses can create, maintain, edit, and analyze reports in a collaborative, protected environment—without relying on IT. To build this solution, 90 Degree Software took advantage of the Microsoft® .NET Framework 3.0 managed programming model, including Windows® Communication Foundation and Windows Presentation Foundation. By using cutting-edge Microsoft technology, developers increased their productivity and released a robust product that enables people to work in a peer-to-peer manner without requiring any server components. As a result, Radius90 reduces the burden on IT and enables analysts to be more productive.
http://www.microsoft.com/casestudies/casestudy.aspx?casestudyid=201506
If you’re using Microsoft peer-to-peer technologies like 90 Degree Software, we want to hear from you!
Email me: tylbart at Microsoft.com
Have fun!
Tyler
I wanted to follow-up my previous posts with a positive report. I took a well deserved vacation last week to Disneyland. We stayed at the Paradise Pier Hotel which offers internet access in the guest rooms. I couldn’t resist testing the PNRP and Teredo experience. I am pleased to report that everything behaved perfectly. Teredo properly received a global address and I could ping the seed server with no problems. There was no need to perform any manual troubleshooting. I know this blog tends to focus on the things that don’t work, but it is good to hear that most of the time things do. Especially when you are on vacation.
-Travis