The Cable Guy - November 2003
Windows Peer-to-Peer Networking
Peer-to-peer networking is the utilization of the relatively powerful personal computers (PCs) that exist at the edge of the Internet for more than just client-based computing tasks. The modern PC has a very fast processor, vast memory, and a large hard disk, none of which are being fully utilized when performing common client/server computing tasks such as e-mail and Web browsing. The modern PC can easily act as both a client and server (a peer) for many types of applications.
Peer-to-peer networking has the following advantages over client/server networking:
- Content and resources can be shared from both the center and the edge of the network.
- A network of peers is easily scaled and more reliable than a single server.
- A network of peers can share its processor, consolidating computing resources for distributed computing tasks.
- Shared resources of peer computers can be directly accessed.
- Allows for efficient multipoint communication with having to rely on IP multicast infrastructure.
Peer-to-peer networking enables or enhances real-time communications (RTC), collaboration, content distribution, and distributed processing.
To address the need for platform-based peer-to-peer networking capabilities, Microsoft has developed and released Windows Peer-to-Peer Networking, which is included in Windows XP Service Pack 2 (SP2). For computers running Windows XP with Service Pack 1 (SP1), you must obtain and install the Advanced Networking Pack for Windows XP, a free download from Microsoft. You can also download threedegrees (3'), a free application that uses the Windows Peer-to-Peer Networking platform to listen to a shared play list, send digital photos, and initiate group chats with MSN Messenger.
On This Page
- Windows Peer-to-Peer Networking Architecture
- For More Information
Windows Peer-to-Peer Networking Architecture
The basic architecture of Windows Peer-to-Peer Networking is shown in the following figure.
If your browser does not support inline frames, click here to view on a separate page.
The basic architecture of Windows Peer-to-Peer Networking consists of the following:
- Identity Manager Enables the creation and management of peer-to-peer identities.
- Graphing Responsible for maintaining a set of connected nodes known as a graph and providing flooding and replication of data across the graph.
- Grouping The security layer provided on top of a graph. The security layer defines the security model behind group creation, invitation, and connection to a group.
- Peer Name Resolution Protocol (PNRP) Provides peer-to-peer name resolution.
- Microsoft TCP/IP version 6 protocol The transport over which Windows Peer-to-Peer Networking operates. For more information about additional capabilities included with the Advanced Networking Pack for Windows XP, see IPv6 Features in the Advanced Networking Pack for Windows XP, the April 2003 Cable Guy article.
Windows Peer-to-Peer Networking exposes or uses the following application programming interfaces:
- Crypto API The Identity Manager component uses functions in the Crypto API to perform common cryptographic functions such as creating and verifying certificates and digital signatures.
- Win32 API Windows Peer-to-Peer Networking functionality is available through a set of Win32 functions for grouping, graphing, identity management, and more. For more information, see Windows XP Peer-to-Peer API Documentation. To develop Windows Peer-to-Peer Networking applications, you must install the Microsoft Windows XP Peer-to-Peer Software Development Kit (SDK).
- Windows Sockets API The Graphing, Grouping, and PNRP components use Windows Sockets API to communicate over IPv6.
In the following sections, we will examine the PNRP, Graphing, and Grouping components in more detail. For more information about these components, see Introduction to Windows Peer-to-Peer Networking.
Instead of relying on the Domain Name System (DNS) to resolve names for peer communication, Windows Peer-to-Peer Networking uses PNRP, which has the following advantages over DNS for peer-to-peer applications:
Windows Peer-to-Peer Networking solves this problem with a name resolution and peer discovery scheme with the following attributes:
- Distributed and serverless for name resolution
Like DNS, the complete list of names is stored on computers throughout the cloud. Unlike DNS, there are no servers that provide name resolution. Each peer stores a portion of the list in its cache and can refer to other peers. Central servers are not used to resolve names. Windows Peer-to-Peer Networking is not strictly serverless, as there is a seed node that facilitates initialization.
- The use of identifiers (IDs) instead of names
Rather than using a name, such as a fully qualified domain name in DNS, IDs are used to identify peer entities. IDs are just numbers and therefore are not subject to language and trademark or copyright issues.
- The use of multiple IDs
Each separate peer computer, user, group, device, service or other type of peer node can have its own peer ID.
- Ability to scale to large numbers of IDs
The list of IDs is distributed among the peers using a multi-level cache and referral system that allows name resolution to scale to billions of IDs, while requiring minimal resources on each node.
Peer Names and PNRP IDs
A peer name is an endpoint for communication, which can be a computer, a user, a group, a service, or anything else that you want to resolve to an IPv6 address, protocol, and port number. PNRP IDs are 256 bits long and are composed of the following:
- The high-order 128 bits, known as the peer-to-peer (P2P) ID, are a hash of a peer name assigned to the endpoint.
- The low-order 128 bits are used for the service location, which is a generated number that uniquely identifies different instances of the same P2P ID in the same cloud.
The 256-bit combination of P2P ID and service location allows multiple PNRP IDs to be registered from a single computer.
For each cloud, each peer node manages a cache of PNRP IDs that includes both its own registered PNRP IDs and the entries cached over time. The entire set of PNRP IDs located on all the peer nodes in a cloud comprises a distributed hash table.
Each entry in the PNRP cache contains the PNRP ID, a certified peer address (CPA), and the IPv6 address of the registering node. The CPA is a self-signed certificate that provides authentication protection for the PNRP ID and contains application endpoint information such as addresses, protocol numbers, and port numbers.
The name resolution process consists of resolving a PNRP ID to a CPA. After the CPA is obtained, communication with desired endpoints can begin.
PNRP Name Resolution
When a peer wants to resolve the peer name to its address, protocol, and port number, it constructs the P2P ID based on the peer name. The peer examines the entries in its own cache for an entry that matches the P2P ID. If found, the peer sends a PNRP Request message to the peer with the P2P ID and waits for a response. This behavior ensures that the peer node with which communication is desired is active in the cloud.
If a matching entry in its cache is not found, the peer sends a PNRP Request message to the peer that corresponds to the entry that has a P2P ID that is numerically closest to the P2P ID being resolved. The node that receives the PNRP Request message examines its own cache. If found, it forwards the request to the intended node and the intended node sends a response back through the request path. If not found, it sends a PNRP Request message to the peer that corresponds to the entry that has a P2P ID that is numerically closest to the P2P ID being resolved, and so on until the correct peer is found.
For example, is Peer A has entries for its own PNRP ID (200) and the PNRP ID of 450 and 500 and wants to resolve the PNRP ID of 800, the following process occurs:
- Because 500 is numerically closer to 800, Peer A sends a PNRP Request message to the node that registered the PNRP ID of 500 (Peer C).
- Peer C does not have an entry for the PNRP ID of 800 and does not have any entries that are closer to 800. Peer C sends a response back to Peer A.
- Because 450 is the next numerically closer PNRP ID to 800, Peer A sends a PNRP Request message to the node that registered the PNRP ID of 450 (Peer B).
- Peer B forwards the request to the IP address that registered the PNRP ID of 800 (Peer E). Although Peer B has an entry for Peer E in its cache, the existence of the cache entry does not assure that Peer E is currently available on the network.
- Peer E sends a response back to Peer B.
- Peer B sends a response back to Peer A.
This process is shown in the following figure.
In the figure, the dotted line arrows from one node to another means that the node from which the arrow originates has an entry in its cache for the node to which the arrow is pointing.
A peer graph, or graph, is a set of nodes that are multiply connected to form a coupled network of nodes for the purposes of propagating data in the form of records or point-to-point data streams. Graphing provides an application-layer multicast capability without requiring an IP multicast infrastructure.
A peer graph node is a peer connected to a peer graph. A graph is built based the connections of neighbors. A neighbor in a graph is a peer graph node that is one graph hop away (is directly connected via a TCP connection).
Connecting to a Graph
When initially connecting to a graph, a peer node connects to a node that is already connected to the graph. The peer node determines the address of the peer node connected to the graph and sends it a solicitation to join the graph. After connecting to the graph, the new peer node creates connections to additional neighbors within the graph.
The purpose of a graph is to create a logical topology for the flooding of messages to all graph nodes. To automatically achieve the optimal topology for flooding, the graph maintains a signature, a set of contact nodes, and evaluates duplicate flooded messages to determine which neighbors are more efficient. Over time, connections are created and removed so that the graph converges to a topology that is optimal for flooding.
When a node disconnects from a graph, it can potentially create a break in the graph known as a graph partition. Peer nodes use the graph signature and graph contact information to detect and repair a graph partition.
Security for a graph defines the following:
- Who can connect and send data to the graph (connection authentication, confidentiality, and integrity)
- How the traffic sent over the graph is encrypted (message/record confidentiality)
- How the traffic sent over the graph is validated (message/record integrity)
Windows Peer-to-Peer Networking provides graph security through the Microsoft Peer Grouping security provider.
Grouping is the combination of PNRP, peer graphing, and the Microsoft Peer Grouping security provider. The Microsoft Peer Grouping security provider provides for the management of the credentials of the members of a group and the secure publication of records in a group. The security provided by Windows Peer Grouping is a combination of the following:
- Peer Names
Group security uses a secure peer name, protected with the private key of the peer name's corresponding CPA, to identify each member of the group. Group security also uses a peer name to identify a group. When a group is created, a new public/private key pair for the group is created, upon which the group peer name is based. The member that owns the private key corresponding to the peer name of the group is the group owner.
- Group Membership Certificates (GMCs)
To participate in a group, every member must have credentials that are used to prove group membership when performing group functions such as connecting to a group or publishing records in a group. These credentials are self-signed X.509 certificates known as GMCs.
Creating a Group
An application on a peer node creates a group by:
- Creating a Group Root Certificate (GRC), signed with a private key owned by the group owner
- Registering the group ID of the group with PNRP
- Configuring a set of group security policies
- Issuing invitations
Joining a Group
To join a group, a peer node must first receive an invitation from the group owner. To receive an invitation from the group owner, the tentative group member must first pass identifying materials to the group owner, which are the peer name and its public key. This information is passed using an out-of-band process such as email, file sharing, XML, etc. The group owner then issues the invitation to the tentative group member.
Upon receipt of the invitation, the tentative group member uses the invitation information to connect to the graph for the group. To connect to the group, the tentative group member uses PNRP and the group ID to resolve the address of a group member.
The tentative group member passes the GMC that was received with the invitation to the current group member. The current group member validates the GMC of the tentative group member and passes its own GMC to the tentative group member. The tentative group member then validates the GMC of the current group member.
After mutual authentication, the tentative group member is now a new group member that has a single neighbor, the graph node that accepted the connection and with which the authentication occurred. The new group member gets the current set of records for the group from the current group member.
Over time, the new group member uses graphing to establish multiple neighbor connections and optimize the shape of the underlying group graph for flooding.
For More Information
For more information about Windows Peer-to-Peer Networking, consult the following resources:
For a list of all The Cable Guy articles, click here.