PNRP and a custom Seed Server? How? RRS feed

  • Question

  • Hi guys,

    I've been reading up on PNRP for the past 2 days and I have to say I'm really excited about this technology.
    I have a couple of questions that I hope you can answer for me

    Let's say I'm building an app that will be deployed in a "corporate" network - multiple subnets, but NO public internet connectivity. From what I've read regarding PNRP, the multiple-subnet thing eliminates the LinkLocal clouds, correct? I'm not 100% sure about this, since I thought the whole idea behind IPV6 was not to worry about subnets/NAT.
    Is this presumption correct or incorrect? Can I use a LinkLocal cloud across multiple subnets?

    If I can't, it seems I have 2 options:
    The MS-provided Global cloud or, I can create my OWN, private global cloud, and all I'd have to do is modify the HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NET\CurrentVersion\PeerNet\PNRP\IPV6-Global\Global_ reg key to point to my own seed server. Since my corporate network in question does not have public connectivity, this private cloud is my only option.

    I've read all I could find on creating my own Seed Server and all I found from the p2p blog is:

    A seed server is just a well known PNRP node that can be used for bootstrapping.  Microsoft maintains a number of seed servers on the public internet behind pnrpv2.ipv6.microsoft.com and pnrpv21.ipv6.microsoft.com.  By default, PNRP v2.0 clients use these servers to start participating in the global cloud.

     Any computer running pnrp can act as a seed server, it just needs to keep one name published at all times.  A PNRP node without a name published will go dormant and stop learning about the cloud as it changes.

    The easiest way to keep a name published is to setup a Windows Internet Computer Name (WICN) on a machine running Windows Vista.   Instructions to guide you through WICN setup can be found here:


    It seems creating a custom seed server shouldn't be too difficult, however, how exactly would I go about doing it? From what I understand a seed server is just a regular P2P node with a known name? Known IP? What exactly? How do I run such a node? Is it just another WCF endpoint using let's say the NetTcpBinding and listening on the address/port combo I specify in the Global seed serve registry key?


    Friday, November 16, 2007 10:08 PM

All replies

  • Hello,

    If your corporate network does not have internet connectivity, then having your own seed server is indeed a good option.

    You are correct - a custom seed server is nothing more than a regulat p2p host that
    1. Always has a name registered (this way it keeps participating in the cloud and doesn't go dormant)
    2. Has a known name or IP that can be reached from anywhere inside your network

    And that's it!  You don't need to write any code or use WCF to configure your seed server.

    So let's say you chose a machine named myseed to be your seed server.

    1. Make sure PNRP is allowed through the firewall
    2. Register a name on it (i.e. 0.myseed), either programatically, or using netsh, or using WICN.
    3. Now you need to make all the other machines use your seed server.  This can be done in several ways.  Choose one of the below options.  They're listed in order of preference Smile
    a. If you can, use group policy.  There is an option there for setting the seed server.  This is the most elegant solution, since you only have to do this on the domain controller, and all the affected machines will change their settings.
    a. Since not everybody has access to a domain controller and group policy, you can also set the seed server on a per-machine basis using netsh.  Run netsh p2p pnrp cloud set seed myseed Global_ on each machine
    b. The previous option would have done this for you, but you can also edit the registry key (on each machine) HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NET\CurrentVersion\PeerNet\PNRP\IPV6-Global\Global_ to point  to your seed server
    c. Lastly, the least appealing but still working option is to edit the hosts file on each machine to remap pnrpv2.ipv6.microsoft.com and pnrpv21.ipv6.microsoft.com to your seed server.  This is not a good long-term solution, in case sometime in the future a pnrp upgrade will require the use of something like of pnrpv3.ipv6.microsoft.com

    4. After changing the seed server, restart the pnrp service or restart the machine.  When the service is restarted, it will attempt to bootstrap from your new seed server.

    To test that it worked, use netsh p2p pnrp di pi se (shorthand for diag ping seed) and you should see you node pinging your seed server.  Don't forget that the firewall needs to be letting PNRP through on all the nodes.  FYI, one easy way to open the firewall for all Windows p2p activity is to simply run the Vista app Windows Meeting Space.

    Let me know if this works for you, or if you have any additional questions.

    Saturday, November 17, 2007 9:13 PM
  • Hi Vladimir,

    Thanks for your prompt reply!

    I'm starting to see how this whole thing works, but still have some questions.

    1. Our app is going to be .NET all the way, so I'm guessing the best way to register a P2P node is to use the new 3.5 classes in the System.Net.PeerToPeer namespace, correct? The way I understand it, these classes basically wrap the PNRP functionality. Just glancing at it, it seems the PeerNameRegistration class is a good place to start.

    2. I can't seem to find any classes that let me programmatically change the Global_ seed info. It seems I have to use "netsh"? However, unless I'm missing something, the "netsh" context stays "active" only as long as the process (in this case, cmd) is running. So to set the seed server using "netsh" I'd have to keep a "netsh" context running inside a command-line window? Not very elegant Smile Isn't it better in that case to just transparently change the reg. key? The down-side I guess to that is that the machine can no longer see any other Global_ cloud, but at least there won't be a "scary" command-line window just running there.

      Is there an API (Win32 API we could wrap would work too) that would let me change the current machine's seed server?

    3. Ipv6/PNRP is still kinda new to me, so this syntax for registering P2P nodes is a bit confusing. What does 0.myseed mean? Is this syntax documented somewhere? myseed is the hostname (I guess has to be in DNS), what does the 0 mean?

    4. I noticed that the Vista SDK (essentially .NET 3.0) comes with a WCF PeerNet example that does NOT use PNRP, it uses a custom "resolver". This resolver looks like a WCF service that just exposes an ednpoint through the NetTcpBinding and acts as a seed server. Is this solution also viable across multiple subnets inside a corp. network? This seems also a good way to go, since it seems "lower impact" (no netsh, no reg. keys). Or should we go the PNRP route? What do you recommend? 
    Monday, November 19, 2007 4:55 PM
    1. That's correct.  System.Net.PeerToPeer is a managed wrapper over PNRP.  If you are developing a managed app, it's definitely the right thing to use.  On a related note, you might also want to check out PeerChannel, which is the managed p2p messaging framework that is a part of WCF (and can use PNRP to find participating nodes).

    2. There is no API to programmatically change the seed server address.  You have to either use group policy, netsh, or alter the registry key in some other way (both group policy and netsh essentially result in setting this key).  However, it's not as bad as it looks!  If you're using netsh, you only have to issue the "p2p pnrp cloud set seed" command once.  This will set the registry key for the specified cloud, and it will remain there until  something (either you or your domain controller via group policy) changes it again.  So there is no need to leave cmd windows open Smile  If you need a custom seed server, you can "set it and forget it" - for example during your app's installation.  The machine can only have one global cloud at a time.  Apart from the MSDN docs, you might find this writeup on PNRP clouds interesting.  Among other things, it talks about troubleshooting when clouds aren't behaving as expected.

    3. Good question - I should've clarified that what I'm talking about here is Peer Names.  This has everything to do with PNRP, and nothing to do directly with IPv6 or hostnames.  Peer names are the very identifiers that PNRP resolves to endpoints, and when you are developing your PNRP application, you will certainly have to register and resolve them.  You can find full information on peer names here and a more brief reference here.  So 0.myseed is an example of an unsecured peer name.  The left hand side is the Authority, and in this case the 0 means that there is no certificate-based authority, making it an unsecured name with no guarantees of ownership.  The right hand side is called the Classifier, and is simply the user friendly name of a resource.  It does not have to correspond to a hostname - it can be any unicode string 150 characters or less.  The above docs explain all this better than I can Smile

    4. The managed P2P SDK essentially gives you 3 different options for a resolver
      1. Custom resolver (for advanced usage).  This lets the developer write their own resolver "plugin" for the interface to use.  This is the most work for the developer, but gives you the ability to implement your own resolving logic, for example you might resolve using DNS, WSD, a custom protocol, etc.
      2. PNRP resolver.  Like the name says, it uses PNRP to find nodes to connect to.
      3. Default custom TCP service resolver.  This is the one that you're referring to.  Like you said, it is analogous to a seed server.  The service listens on a TCP endpoint, keeps a cache of mesh IDs, and lets clients perform resolutions.


    There are some useful links to information about the SDK and examples using the different resolvers on the Peer Channel team blog


    If you are using PeerChannel, you would most likely be interested in either the PNRP or the TCP resolver, and each has some benefits and drawbacks.  It's true that the TCP resolver does not use the registry, and indeed it should work fine across subnets and across the internet.  However, there are some deployment costs.  I will try to contrast them with analogous PNRP concepts so that you can see how the tradeoffs fit into your application's architecture



    TCP Resolver


    Server setup

    You are responsible for the uptime  and connectivity of the machine that will be running the service.

    In the case of the default global cloud, Microsoft takes the responsibility of running the seed server. 

    Client setup

    All client machines must be configured (at setup, programmatically, etc) to know about the server's endpoint.

    Admins don't have to open up their firewalls to PNRP traffic, though they do need to enable exceptions for the resolver service.

    If using the default global cloud, client machines are already aware of the Microsoft seed server.  If using a custom seed server, they must be configured (through GP, netsh, registry) to know the seed server's address.  If the machines are on a subnet, PNRP will use SSDP to let them discover each other even if the seed server is not reachable.  PNRP traffic has to be allowed through the firewall in all cases.

    Scalability and Reliability

    Essentially a dictionary of mesh IDs and endpoints running on a single machine.  All resolve requests will go to the server.  The developer is free to modify the code to add multi-threaded logic, throttling, etc.

    Designed to be an internet-sized, distributed framework.  It aims to eliminate bottlenecks by having the peers cooperate in resolving names.


    None built in as far as securing names - the developer can choose to implement custom security logic.  This might not be relevant depending on the application (i.e. everybody is a trusted user on a secure corpnet)

    As far as the actual communication between the client/service, it can be configured to use various WCF TCP security options.

    Gives the option of using secure names, which use public/private key pairs to secure name ownership.  I.e. if I register a secure peer name in PNRP, you can be assured that when you resolve it, only I (the legitimate owner of the name) will be able to supply you with the resolved endpoint.


    So as you can see, the TCP resolver would be a good fit for a smaller scale deployment, lightweight application, whereas PNRP scales from small simple to internet-sized and complex.

    Tuesday, November 27, 2007 11:21 PM
  • Hi,


    How can I configure security on the name resolution communication. In the custom resolver tag there is no way to specify a behavour?






    Friday, October 3, 2008 11:49 AM