Microsoft Peer-to-Peer Networking

A Simulation Sample

p2p — Fri, 06 Feb 2009 02:56:00 GMT

We have some sophisticated infrastructure that allows us to simulate many peer-to-peer systems, scaling up to millions of nodes in size. The nodes in our simulation run the exact same DRT binary that ships with Windows 7. We can simulate a number of different systems – small networks where nodes come and go, large networks that remain stable, even networks where nodes behave maliciously or drop offline without warning.

In this entry, we’ll focus on two performance metrics (resolve success rate and average hopcount), in two scenarios (stable cloud and dynamic cloud).

. Resolve success rate: # successfully resolved keys/ # issued resolutions

. Average hops: average number of nodes that must be contacted in order to resolve a key

Scenario 1: Stable network with low churn (a private enterprise network or a data center)

In this scenario, the network is stable. Machines rarely join/leave. They stay in network, register/unregister keys, and search for other keys. Here is the result of one sample simulation with 2000 DRT instances (nodes). It shows that the resolve success rate is always above 99.9% (Figure 1), and keys can be found within about 3 hops (Figure 2).

Scenario 2: Network with high churn (an Internet DHT)

Applications deployed in Internet may experience churn: machines can leave, join, or suddenly fail. To understand the performance of the DRT when the system is very dynamic, we simulate higher churn rates than we expect in reality. Nodes frequently join and leave the system. 20% of nodes disappear suddenly – disconnecting without notifying others. The simulations show the DRT maintains a high resolve success rate (>98.5%) (Figure 3) even under such adverse conditions. Searches complete within 6 hops on average (Figure 4), which indicates DRT cache is well maintained.

Thanks!

Xianjin

Introducing the DRT SDK Sample

p2p — Tue, 03 Feb 2009 08:56:00 GMT

Overview

We’ve already had a few posts describing the DRT and what it does, but now we can actually show it off! This post is designed to provide a brief but useful look at the DRT SDK Sample.

The DRT SDK Sample demonstrates how to:

· Initialize the DRT_SETTINGS structure

· Use and attach a variety security and bootstrap providers

· Add an exception for the DRT to the Windows Firewall

· Register and unregister keys in the DRT

· Perform various types of DRT Searches

Getting Started

Each time the sample is executed, it creates one DRT node. In order to create a useful DRT, multiple nodes are required. These can be run either locally with multiple nodes on the same machine, or across a network with nodes on different machines.

Security Provider

Upon startup, the DRT SDK Sample prompts for which security provider to use. The security provider is used both for identity verification, to ensure that a node has the right to participate in the DRT, and for confidentiality of the DRT payload. The sample has three security provider options:

· Null Security Provider – A bare-bones security provider that allows any node to publish any key. It does not perform any encryption on the DRT payload, and is useful for debugging and prototyping.

· Derived Key Security Provider – This provider secures keys using X.509 certificates, and chains them to a common root. Nodes can only publish a key if they have a valid X.509 certificate derived from the common root. Also, the key that they publish is derived from the SHA-2 hash of the public key embedded in their certificate. The payload is encrypted using the public/private key pairs. Since this provider requires the generation of certificates, the setup is slightly more complicated. Checkout the section on the derived key security provider below.

· Custom Security Provider – This provider is based on the null security provider. It is also a bare bones security provider that only performs serialization of the data, without encryption. The difference is that the code for this provider is available in CustomSecurityProvider.cpp and provides a useful base for the creation of a customized security provider.

Derived Key Security Provider

The DRT SDK Sample contains code to automatically generate certificates when using the Derived Key Security Provider (DKSP). The certificates will be generated and saved in the current directory. Therefore, when using the DKSP, each DRT Instance should be started in its own folder.

As mentioned above, the DKSP requires the certificates of all instances to be derived from a common root certificate. The easiest way to accomplish this is to start one DRT Instance using the DKSP. Both a root and client cert will be generated. Then simply copy the root certificate into the folder of each of the other DRT Instances before starting them. If a root cert already exists, the DRT SDK Sample will generate client certs based on that root cert.

Bootstrap Provider

In order to join an existing DRT, a new DRT node must be able to “discover” peers that are already joined to the DRT. This is the role of the bootstrap provider. A new DRT node can bootstrap from any already joined DRT node that is currently publishing a key.

· DNS Bootstrap Provider – The DNS bootstrap provider bootstraps using DNS. It accepts the computer name, either a FQDN or the hostname of a computer on a local network as well as the port that the remote DRT instance is listening on.

· PNRP Bootstrap Provider – The Peer Name Resolution Protocol (PNRP) bootstrap provider uses PNRP to bootstrap the DRT. It accepts the peer name (for example 0.somename), performs a PNRP resolve for that name, and then bootstraps from one of the endpoints that it finds. *To use the PNRP bootstrap provider the PNRP port, 3540, must be opened in the Windows Firewall. The sample will open the firewall as necessary provided it has sufficient privileges.

· Custom Bootstrap Provider – The custom bootstrap provider is based on the DNS bootstrap provider. The difference is that the code is available in CustomBootstrapper.cpp, and is a useful example of how to write an application-specific bootstrap provider.

Initialization

After selection of a security provider and bootstrap provider, the DRT will attempt to bootstrap. If other peers cannot be found, the DRT will transition to the ALONE state. This is expected for the first DRT instance that is started since no other nodes exist in the mesh.

The first DRT instance should publish a key so that subsequent instances can bootstrap from it. This can be accomplished by choosing menu option 1. In the case of the Null Security Provider or Custom Security provider, choosing option 1 will produce a prompt for a DRT Key to register. If the Derived Key Security Provider is used, a new certificate will be generated based on the root cert, and a DRT Key based on a hash of the newly generated cert will be published.

Subsequent DRT Instances should transition to the active state as they join the mesh.

Searching

The DRT key space is circular and each key is 256 bits. A wide variety of searches can be performed by specifying various options in the DRT_SEARCH_INFO structure. The DRT SDK Sample highlights the most commonly used scenarios:

· Simple DRT Search – This search uses the default options for the DRT_SEARCH_INFO structure. It is an exact match search throughout the entire number space except that it will exclude keys published by the current DRT Instance.

· Nearest Match Search – This search also searches throughout the entire number space for a key, but rather than failing if the exact key is not found, it will return the closest key that exists to the one that was specified. This search can be modified to return more than one nearest match by changing SearchInfo.cMaxEndpoints.

· Iterative Search – This search is the same as the Simple DRT Search except that it will fire the SearchEvent, and provide an intermediate match, for each hop during the search.

· Range Search – This search prompts for a target key, and a min key and max key for the range. This search will return the first match it finds that falls within the specified range. Since the number space is circular, min and max have no real meaning. Thus, the target key is used to determine which “side” of the range to search. This search also can be modified to return the closest key to the target within the specified range by setting SearchInfo.fAnyMatchInRange to FALSE.

Have Fun

Hopefully, this post gives a good overview of how to use the DRT SDK Sample, and helps to highlight some of the basic uses of the DRT. Although the SDK Sample covers many different security providers, bootstrap providers, and search types, we tried to keep the code easy to read and straightforward. I look forward to your questions and comments.

Thanks!

--Bill

Building a Distributed Hash Table with the DRT: Part 2

p2p — Wed, 28 Jan 2009 02:59:00 GMT

In the previous article in this series, we introduced the concept of a Distributed Hash Table (DHT) and explained that the DRT makes it easier to build a DHT by offering key based routing. In this article, we’ll describe an architecture for a DHT that uses key based routing. Next time, we’ll start looking at the actual DRT data structures and API calls in a real DHT implementation.

Like every other DHT, ours will allow machines to store and retrieve BLOBs (Binary Large Objects) using the operations put and get. This is really no different from a traditional hashtable that runs on a single machine. When an application calls put, it must supply the object that it wishes to store, and the key that represents that object. When an app calls get, it must supply the key representing the object it wishes to retrieve. Unlike a traditional hash table, a DHT allows multiple machines to simultaneously execute many get and put operations. BLOBs can be accessed and modified by multiple computers. Machines may join and leave the DHT and BLOBs will not be lost.

In our DHT, each node will represent itself with a node ID. The node ID will be a 256 bit number that must be unique amongst all the machines participating in the DHT network. When a node starts up, it will use the DRT API to publish its node ID, so that it can be discovered by peers. Using the DRT API, it is possible to search for other machines by node ID. It is also possible to search for the machine having a node ID closest to an arbitrary number. Just to be crystal clear, here’s an example: In my DHT I have six computers having node Ids 100, 261, 301, 455, 671 and 802. If I use the DRT API to find the machine publishing a node ID closest to the number 300, I will find the node with node ID 301.

This ability to find the machine with a node ID closest to a given number is critical in the implementation of a DHT.

Let’s look under the hood of a put operation. The application calls our DHT put method, supplying the BLOB to store and the key to identify it. Our DHT uses the DRT API to find the computer with the node ID closest to the key supplied by the application. This computer will become the new owner of the BLOB. The source computer retrieves the IP address and port of the target machine using the DRT API. It establishes a TCP connection and sends the BLOB to the target computer.

The get operation is very similar. The application calls our DHT get method, supplying the key of the object it wishes to retrieve. Our DHT uses the DRT API to locate the computer with the node ID closest to the key. It retrieves the IP address and port that the target computer is listening on, establishes a TCP connection. It communicates the key representing the object it wishes to retrieve, then downloads the object and supplies it back to the application.

This is all well and good, but what happens if a node goes offline? All of the BLOBs that it had previously stored disappear, right? To prevent this from happening, each node replicates its BLOBs to the machines having node Ids numerically closest to its own (its neighbors). If a node disappears, its neighbors are ready to take over. They can service get requests for keys that the departed node used to be responsible for. The DRT API raises events when neighboring nodes leave and when new neighbors join. The DRT API tracks the five computers publishing keys numerically greater and the five machines publishing keys numerically smaller than a published key. This group of ten machines in total is called the leaf set.

That’s all for now. Next time we’ll start looking at the DRT data structures and function calls that make all this actually happen.

Have fun!

-Tyler

Windows 7 Peer-to-Peer Resources

p2p — Wed, 28 Jan 2009 01:47:00 GMT

Hi everyone,

I just wanted to post a short list of resources that will help you build peer-to-peer applications for Windows 7.

Download the Windows 7 beta here: http://www.microsoft.com/windows/windows-7/beta-download.aspx. If you haven't tried it yet, be quick! Looks like beta slots are running out.

Donwload the SDK for Windows 7 here: http://www.microsoft.com/downloads/details.aspx?FamilyID=a91dc12a-fc94-4027-b67e-46bab7c5226c&DisplayLang=en. The SDK includes everything you need to build applications with the Distributed Routing Table - headers, libraries and even a sample.

Access the DRT MSDN Documentation here: http://msdn.microsoft.com/en-us/library/dd407952(VS.85).aspx. Let us know if you feel concepts are left unexplained or if you have any questions.

Have fun!

-Tyler

Building a Distributed Hash Table with the DRT: Part 1

p2p — Fri, 09 Jan 2009 23:23:00 GMT

This is the first article in a multi-part series describing a design for a distributed hash table (DHT) built with the Distributed Routing Table (DRT), our new Windows 7 peer-to-peer platform piece. If you’re interested in building a DHT of your own using the Distributed Routing Table, or you have questions about these articles, please email me (tylbart@microsoft.com). I can answer questions, point you towards the right documentation and help you get the tools you need to get started.

Distributed Hash Tables have received lots of well deserved attention from academia and industry. They have been used to build some powerful (and sometimes disruptive) software, and have many properties and architectures worthy of deep analysis.

Wikipedia has brief, but informative introduction to DHTs which is worth reading even if you’re an experienced peer-to-peer developer (http://en.wikipedia.org/wiki/Distributed_hash_table).

Here’s a DHT definition lifted from the Wikipedia article:

Distributed hash tables (DHTs) are a class of decentralized distributed systems that provide a lookup service similar to a hash table: (name, value) pairs are stored in the DHT, and any participating node can efficiently retrieve the value associated with a given name. Responsibility for maintaining the mapping from names to values is distributed among the nodes, in such a way that a change in the set of participants causes a minimal amount of disruption. This allows DHTs to scale to extremely large numbers of nodes and to handle continual node arrivals, departures, and failures.

DHTs form an infrastructure that can be used to build more complex services, such as distributed file systems, peer-to-peer file sharing and content distribution systems, cooperative web caching, multicast, anycast, domain name services, and instant messaging. Notable distributed networks that use DHTs include BitTorrent's distributed tracker, the eDonkey network, YaCy, and the Coral Content Distribution Network.

The Wikipedia article goes on to describe the software components comprised by a typical DHT. There are three basic pieces:

1. A mechanism for finding the machine responsible for a key, value pair when storing or retrieving a piece of content.

2. A protocol for transmitting or downloading a key, value pair.

3. A protocol and a set of algorithms that preserve the key, value pairs while allowing for the arrival and departure of new machines in the distributed system.

The DRT solves problem number (1) and provides tools that make it easier to solve (2) and (3).

The structured overlay (component 1) is perhaps the most keenly studied component in today’s distributed hash tables because it’s a hard piece of software to get right. A lot of Microsoft blood, sweat and tears went into the DRT, but we’ve come emerged with a high quality protocol that can greatly simplify the development of a DHT. The DRT is based on the PNRP protocol, and has benefitted from our years of study of the PNRP cloud on the real Internet. The DRT has been extensively tested for security, reliability, performance and scale. We have world class simulation infrastructure that allows us to test DRT clouds with millions of virtual nodes under adverse network conditions. Finally, we have rebuilt the PNRP component in Windows 7 using the new DRT platform, and we have a new experience using PNRP in remote assistance.

With all this said, the DRT won’t be complete until we get some feedback from you. Please let me know if you would like to test the DRT or build an application of your own (DHT or otherwise) before we ship Windows 7. You can have a big impact on our product!

The rest of the articles in this series will describe how to program the DRT to be an effective overlay for a DHT. We’ll also talk about some protocols and algorithms for content download/upload and replication and look at some alternative DHTs and overlays in production today.

Thanks and have fun!

-Tyler

Peer-To-Peer based Features in Win 7

p2p — Wed, 19 Nov 2008 09:55:00 GMT

Perhaps you watch ABC’s Extreme Makeover: Home Edition. If you do, then you may know it had a sibling show called Extreme Makeover Home Edition: How’d They Do That? It showed extra behind scenes work on how they pulled off such an amazing feat. Or maybe you are a Discovery Channel buff and find yourself watching How Its Made. If you ever wanted to know how they make common everyday items such as balloons or vegetable oil, that is the show for you. But have you ever wanted to know how your favorite Windows 7 features were made? I would like take a few moments to shed light on how two new Windows 7 features use the Microsoft Windows Peer-To-Peer network platform to provide a great end user experience. I’ll give you a brief overview of how peer-to-peer technologies solved real issues, and how you can use the features in your applications.

To start with lets reintroduce Remote Assistance. The ability to request somebody remotely to help you isn’t exactly a new feature to the windows platform. But Windows 7 has improved it by using PNRP. Windows 7 offers a new connection option called Easy Connect which is, well, an easier way to connect to your friends who can help you. Before you needed to create and email an invitation file. I always hated walking through somebody on the phone how to do that. But now when you click easy connect a series of 12 easy to read characters appears. You can read these over the phone to your expert friend helping you. The other person types them into his instance of remote assistance and the two connect like magic. Except it isn’t magic. It is PNRP. PNRP allows you to publish the endpoint of a service on the internet. In Remote Assistance’s case the service is the Remote Assistance session. The 12 characters are actually a transformed version of a PNRP Peer Name. How does PNRP work? We have published a number of papers describing the protocol in detail and it is beyond the scope of this blog to go over it all again. But simple put there is a “PNRP Cloud” on the internet which is made up of nodes participating in PNRP. When you publish your peername it gets flooded to some members of the cloud. When you search for a PNRP name you are iteratively contacting other participating PNRP nodes in the cloud to find the node that matches your search criteria. This has some tremendous advantages over DNS. For instance, when you register a PNRP name in the cloud it is locatable across the world within a few seconds! If your IP address changes your PNRP registration is also updated, so you don’t have to worry about people connecting to stale addresses. This would work great for any application that needs to connect to other nodes on the fly…especially mobile nodes. PNRP works over IPv6. Chances are you don’t have Native IPv6 at your house. But you probably do a have Teredo connectivity. Teredo is a technology that tunnels IPv6 over IPv4. But it is also great for achieving end-to-end connectivity through your home’s NAT. So by using PNRP Remote Assistance (and your application) can achieve end-to-end connectivity across the internet in seconds, without the need for a game lobby, emailing invitations, or defining custom port mapping rules on your NAT. I’m sure by now you are asking how you can get started writing PNRP enabled applications. If you are a Native Code developer check out PNRP on MSDN and our samples in the platform SDK. If you are a managed code developer check out the System.Net.PeerToPeer namespace in .NET Framework 3.5.

Now let’s look at one of the most anticipated features of Windows 7 for all you home users: HomeGroup. This really enhances the experience when you have multiple PCs in a single house. You can learn more about it here. http://windows7news.com/tag/homegroup/. What does it have to do with the Microsoft Windows Peer-To-Peer Platform? Home group uses the P2P feature called Grouping which has been around since XP sp2. Grouping is a technology that maintains a mesh of connected nodes. Each node maintains a database of records which is kept in sync with all other participating nodes. HomeGroup uses this feature to keep a set of records about resources that are available in that group, such as file shares and printers. As new PCs join the home group it joins the P2P Group, gets flooded the records for the groups, and is quickly able to be full participating member. Although P2P Grouping has the ability to run over the Internet (using IPV6 & Teredo as described above), the HomeGroup feature limits the scope to your local network. P2P Grouping also includes a security model to prevent rogue nodes from joining or getting content without permission. What are good uses for grouping? Any time you wish to synchronize application data between multiple nodes, consider grouping. Since the data is stored locally on each node retrieval time is very fast, especially for larger content which would normally need to be pulled from a server. Imagine the possibilities! To get started check out the Group Chat sample in the Windows SDK. This sample application uses grouping to create a simple chat application. Each message sent is a record in the group, so when you join the chat session you get a full history of the entire chat. It also demonstrates how grouping keeps track of group membership.

The industry as a whole tends to use the phrase “peer-to-peer” only when talking about internet scale file-sharing applications. But here we are trying to redefine it to a much broader definition and are finding uses for it in many applications such as those mentioned here. I look forward to hearing about how use peer-to-peer in your applications.

Thanks!

-Travis

Introducing the Distributed Routing Table in Windows 7

p2p — Wed, 19 Nov 2008 09:53:00 GMT

In Windows 7, we’ve added support for key based routing with a new peer-to-peer platform piece called the Distributed Routing Table (DRT). Applications can use a new Windows API to publish numeric keys, and resolve keys to network endpoints without the aid of servers. This functionality can be the basis of a Distributed Hash Table (DHT) and is fundamental in Microsoft’s Peer Name Resolution Protocol (PNRP). Key based routing can also be used to build peer-to-peer networks of many topologies, greatly simplifying the development applications needing serverless synchronization, flooding or content distribution.

The DRT protocol is based on version 2 of the Peer Name Resolution Protocol. If you’ve read our PNRP whitepaper, and you’re familiar with PNRP concepts, you will have a much easier time understanding the DRT. PNRP allows applications to publish and resolve names without the aid of servers. When resolving a name, PNRP first converts the name to a 256 bit numeric key, and then uses an iterative lookup procedure to traverse a structured overlay and locate the machine publishing the precise target name. The DRT, on the other hand, leaves the application free to define how keys are derived, and provides a rich search API that allows applications to find the nearest keys to a target, or search for keys falling within a range of values. The DRT uses the same iterative lookup procedure and multi-level cache proven successful in PNRP.

DRT keys are a fixed size: 256 bits. Your application is free to define what these keys mean, how they are generated and how they are secured. During initialization, your application must supply the DRT engine with a module known as a security provider. Your security provider understands the meaning of DRT keys in your system, and will be called upon by the DRT engine to process certain messages during the key publication and resolution processes.

The DRT platform includes two fully implemented security providers that are suitable for a broad range of applications. The derived key security provider (DKSP for short) secures keys using X.509 certificates. In a DRT configured with the DKSP, each machine must possess a certificate chaining to a common root, and can only publish a 256 bit key derived from the SHA-2 hash of the public key embedded in that certificate. The DRT platform also includes a NULL security provider, which allows all machines participating in the DRT mesh to publish any 256 bit key. This security provider is not suitable for internet deployments, but is great for prototyping and some applications that will be used in private networks.

Several types of searches are possible using the DRT API. We’ll begin by describing the exact match search, where the application supplies a 256 bit key and the DRT engine locates the node publishing that key. This type of search uses two phases: endpoint determination and key authentication.

During endpoint determination, the resolving node attempts to determine the IPv6 address of the machine publishing the target key. The resolving node communicates with other nodes participating in the DRT, each of which attempts to provide the resolver with the IP address of a node publishing a key numerically close to the target. Each node maintains a structured cache of IP addresses and keys published by other nodes in the cloud, and takes special measures to learn about many nodes publishing keys numerically close to its own.

In the second phase of the lookup, key authentication, the resolving node authenticates the key found in phase one. The security provider on the publishing node’s machine generates a blob of data that can be used to prove ownership of the key. This might be a credential, like a certificate chain. This blob is passed from the publisher to the resolver by the DRT protocol. The security provider on the resolving node’s machine receives the blob, parses it and verifies that the publishing node is indeed authorized to publish the target key.

In addition to the exact match search, the DRT supports nearest match searches, where the DRT protocol locates the nearest N nodes to a target key, and a range search, where the DRT protocol locates N nodes publishing keys within a range of values.

All applications that use PNRP on the internet, participate in one, large peer-to-peer system. With the DRT, application developers can define their own distinct peer-to-peer clouds. The DRT requires the application developer to provide a bootstrap module during initialization time. This bootstrap module is responsible for retrieving the IP addresses of some nodes already active in the DRT system. The bootstrap module might contact a server, or use another protocol like SSDP or PNRP.

Over the next few weeks, we’ll follow up with more posts, diving into the various aspects of the DRT in more detail. In the mean time, feel free to contact me with any questions. tylbart@microsoft.com.

Have fun!

Tyler

PNRP Extended Payload

p2p — Mon, 23 Jun 2008 07:11:00 GMT

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

PNRP and Windows Internet Computer Names on WS08

p2p — Mon, 23 Jun 2008 07:08:00 GMT

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

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

The .Net Addict Discusses PNRP, Bonjour and MDNS

p2p — Mon, 23 Jun 2008 06:59:00 GMT

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

PNRP Performance Counters

p2p — Mon, 23 Jun 2008 06:56:00 GMT

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

PNRP in XP SP3

p2p — Mon, 23 Jun 2008 06:47:00 GMT

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

.Net Addict Hooked on P2P

p2p — Mon, 05 May 2008 21:37:00 GMT

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

Making Sense of Traceroute

p2p — Wed, 07 Nov 2007 10:13:00 GMT

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!

Get Connected With The .NET Framework 3.5

p2p — Thu, 09 Aug 2007 00:23:00 GMT

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