|
|
-
-
So readers, I have a bit of a poll for everyone today. Have any of you written an app that uses PNRP directly or indirectly (via some technology like Peer Grouping or PeerChannel)? If so, we would love to hear from you. Please just use the feedback link on my blog to let us know about you and your app.
If you let me know you have something, I can make sure you get on beta lists, and I can potentially get your app some exposure (we are always looking for apps using our stuff to show off at conferences and such). Even if you do not have something released, I would love to hear about what you are working on.
Thanks!
|
-
I received a couple of email and comment questions about how Internet Computer Names work and whether there is a central server. The cool answer is that no, there is no central server. The whole service is peer to peer based on a technology called PNRP (really ICNs are PNRP names, they just get published for the entire machine rather than a single process as is more normal for PNRP).
Basically, every machine knows about a few other machines basically at random. Those machines know a few others, who know a few others, etc. When I want to resolve someone else's name, I can use all of those relationships to track down the machine publishing the name I want.
Obviously that is jumping over a ton of detail. For more details, check out our overview whitepaper (the PNRP section) at http://www.microsoft.com/technet/prodtechnol/winxppro/deploy/p2pintro.mspx. We also have a new PNRP-specific whitepaper going up sometime next week that should be even better (I will post a comment when it is up).
|
-
I had a very exciting chat with some beta users today where, for the first time, we talked about a feature I am very excited about that we are calling Internet Computer Names. Basically, it is making use of a service we built in Vista that will publish a name for the machine any time the machine is running. Coupled with the way PNRP is integrated into GetAddrInfo, this makes for some awesome experiences like being able to Remote Desktop to your machine from anywhere using a PeerName.
The only negative about the feature is that it is not exposed via a GUI in Vista RTM. Instead, you have to use netsh. However, I am hoping that someone will pull together a GUI for folks to use (hint, hint).
Below are the instructions we gave in the chat on how to enable the service and some ways of trying it out. Let me know what you guys think!
Internet Computer Naming
Have you ever wanted to be able to find and connect to your computer across the Internet, but did not want the complexity and cost of buying a domain name and using Dynamic DNS? With Windows Vista, you can using Internet Computer Naming. This section will show you how to enable the technology, and how to take advantage of it.
Enabling the Service
This service can be used with two types of names, secured or unsecured. The difference is that unsecured names are simple to type, such as JohnDoe.pnrp.net, but can be spoofed, such that the machine you connect to using this name is not guaranteed to really be your machine (i.e., you might not be the only JohnDoe who used that name). Secured names are more complex, like johndoe-p.p4562b4628ac54782dda52789038476237e7c7263.pnrp.net, but will always be your machine. The instructions below will use unsecured names, but you can substitute a secured name by using ‘name=”” ‘ in step 5 below.
Choose a name you would like to use. For simplicity, it should be only lowercase characters, with no special symbols. We recommend your email address without the @ or ‘.’. For example, johndoe@microsoft.com would become ‘johndoemicrosoftcom’. This name will be represented in the instructions below as <name>.
Go to the Start, All Programs, Accessories, and right-click on Command Prompt, selecting Run as Administrator from the menu This will cause a UAC prompt which you should accept, and then you will be presented with a cmd window. In this application, type the following commands.
- “netsh” enter
- “p2p” enter
- “pnrp” enter
- “peer” enter
- “set machinename name=”0.<name>” publish=start autopublish=enable” enter
- “show machinename” enter
- The results of the previous command will include a line beginning “Use this format DNS name…”. After that sentence is the Internet Name for your machine. Write this down, as it will be referred to in the below commands as <internetname>.
Using the Service
Internet Computer Names can be used virtually anywhere in Windows. We will start off with a simple use, and then show a more interesting use.
Ping:
Open a command prompt (Start menu, then type “cmd” enter into the run/search dialog) on either the machine with the name published or another machine. In the window, run the command “ping <internetname>. This ping should succeed, the same way it would if you used an IP address or a DNS name.
Remote Desktop:
Remote Desktop can work with Internet Names as well. Enable Remote Desktop via the following (skip if Remote Desktop is already enabled):
- Start
- Right-click on Computer and select “Properties”.
- On the left side of the resultant window, click “Remote settings”
- Accept the UAC prompt.
- In the new window, click the radio button next to “Allow connections from computers running any version of Remote Desktop” and then click OK.
- Close all windows opened in this process.
Now you can use Remote Desktop to connect from another machine.
- Start
- All Programs
- Accessories
- Remote Desktop Connection
- In the Remote Desktop Connection window, type in your Internate Name for your other machine (<internetname> from above) into the “Computer” field and click connect.
- Login with your normal credentials.
Note that the above will now work from any Vista computer on the Internet that has IPv6 connectivity (this generally means any machine not in a corporate network).
Other Applications:
Again, this name will work with virtually any part of Windows. If you run IIS on your home machine, you can use an Internet Name to access a web site on your home machine, or an FTP site. You can setup an RSS subscription to a feed from your home machine. If you have a multiplayer game where you normally type in IP addresses or DNS names, try an Internet Name.
|
-
A few months back, I did a Channel 9 interview on P2P and Collaboration in Vista. It has been pretty popular on Channel 9 (~30k views), so I thought I would point other folks at it. It is a pretty good 1 hour introduction to the overall P2P/Collab platform in Vista. Let me know if you have questions or want to hear about other points in a follow up video.
http://channel9.msdn.com/Showpost.aspx?postid=165133
|
-
Hey All,
Lots of thanks to everyone who is still subscribed to my feed despite my long absense. I may have disappeared from here, but it was just because I have been spending my every minute working on P2P goodness. We are wrapping up Vista now, and I have a ton of things to talk about, so expect posts to start coming again.
The main things I am going to start talking about are features in the P2P platform to Vista, tips-and-tricks for using those features, and some questions for the community to help prioritize planning for post-Vista.
|
-
I was just scheduling a couple meetings at the PDC with some of our existing partners. If any readers are considering using any of the MS P2P technologies or the new Peer Collaboration technologies, please use the contact link on my blog to get in touch with me and we can try setting up a meeting in LA during the conference.
|
-
Hey!
For those of you coming to the PDC, I will be in attendance along with several others from my team. We will even have a few sessions and events you can check out.
- COM311 - Developing P2P Applications using Windows Vista and the Windows Communication Foundation (“Indigo”) Peer Channel
- COM319 - Windows Vista: Integrating the People Near Me platform into your applications
- Hands on Lab - People Near Me
- Hands on Lab - Indigo PeerChannel
- Birds of a Feather - Using PNRP
- Ask the Experts Dinner - Two Tables, P2P Native and P2P Managed.
I hope to see many of you there!
-Noah
|
-
I just noticed that PNRP and P2P in general have a nice write-up in the Windows Vista Dev Center on MSDN. Check it out at http://msdn.microsoft.com/windowsvista/connected/.
Clip from the center:
Peer-to-Peer
Windows Vista provides capabilities for discovering and communicating between applications without the need for centralized servers. The peer-to-peer capabilities of Windows Vista give users and applications the ability to discover and interact with others on the network in a secure fashion.
Central to the capabilities of the peer-to-peer support in Windows Vista is the Peer Name Resolution Protocol (PNRP), which enables dynamic name publication and resolution. Today, names are assigned to computers in a relatively static fashion along with their IP addresses. PNRP provides a much more dynamic ability to register multiple names on a computer, to have multiple computers register a single name, and to even have applications register names. Name records can contain additional metadata describing the associated resource. All of this is done in a secure fashion that prevents spoofing. Developers can use standard name resolution APIs, like getaddrinfo, to resolve their PNRP names.
Peer-to-peer networking enables multiparty interaction by creating meshes of nodes that self-organize into a robust communication group; messages can be sent to all mesh nodes through one or more hops. New nodes can be dynamically added and removed from the mesh without losing the overall connectivity. Secure meshes can be created with restricted membership. Meshes enable the publication of shared data records that are automatically replicated and persisted among all members. Everyone in the group sees updates to the data immediately, as if it were performed locally.
The Windows Communication Foundation Web service API provides a multiparty messaging channel (called the Peer Channel) that developers can use to create large, scalable meshes for sending and receiving Web service messages.
The peer-to-peer capabilities of Windows Vista also provide the ability for applications to find "People Near Me." This enables developers to create applications that enumerate individuals who are physically near them on the network so that data can be easily shared. Using peer-to-peer APIs, individuals can be invited to participate in activities, such as voice chat or games.
|
-
Well, PNRP has now made VNUNET. So, like all articles, there are a few things good and a few things bad about it. The first thing is that I want to apologize to the world that there was not more MS comment in the article. Unfortunately, the nature of press inquiries is that requests for comment trickle through many layers before they reach those who need to comment, so sometimes it is slower than we would like. For example, I only learned about this request a couple hours before the story was posted. It is, unfortunately, the nature of the beast.
So let me hit some of the good points. Tom does a good job of talking about some scenarios in which PNRP is valuable, such as online gaming. I am pretty stoked that such a mention will help more developers find out about our technology. Tom also nailed the issue of how this affects IDS systems, which is great. Specifically, he explains how this will look like unusual traffic and as such, the IDS systems will raise flags, which is basically a nuisance issue. I would add that betas like this give IDS makers the opportunity to identify new protocols like PNRP for addition to their known behavior sets, stopping issues like this from happening after Vista ships. Finally, he rightly explains that we are not going to have PNRP running by default in the RC releases.
Let me start expanding upon the article a little bit now, starting with the 'enabled by default' issue. This is an interesting issue, and is one that warants discussion. At Microsoft, and particularly in my team, I think we have a great passion for delivering the best software possible. That sounds trite, but it is really true. The issue is that sometimes that leads to conflicts. In this case, we had to balance the default configuration of the beta vs the quality of the final product. By turning PNRP on, we will get a lot of information about how PNRP behaves under different circumstances. We then have the opportunity to improve the protocol before we launch the final product. Fundamentally, what Betas are for is to make sure that we can ship the best possible final product.
There are a couple of other little points about the article that I would like to clarify. The first is the assertion that we are pushing all sorts of information out into the cloud. PNRP itself publishes what it is asked to publish by an app, and no more. Thus, we generally publish the name someone wants to publish (note that this is not necessarily a username, but is whatever the app wants, so it could be a GUID or something like that), the addresses the name should resolve to, maybe a port number, and maybe a short comment set by the app (Usually used for testing). In the case of PNRPAuto which is the service publishing names on LH that has spawned this discussion, we basically just publish a random number for the name and then the machine addresses. Let me reiterate, we are basically publishing a random number into the cloud. As such, we do not post random personal information.
Furthermore on this topic, as of Beta 2 forward, all that PNRP will push to other machines that are not actively resolving for your name (i.e. the stuff we use for routing requests) will just be a hash of your name and the addresses of the machine. At that point, it is quite innocuous info, and again, it is only at the behest of an app.
Another note is regarding security review of the protocol. We are currently in discussions with a couple of security experts about reviewing PNRP. This has been in the works for a while. If there are particular security experts who you would recommend we talk to, please let us know and we will add them to the list of candidates.
There are a lot of other issues in the article that I would like to address, but I think I will save them for some future posts. Stay tuned for more exciting PNRP news!
|
-
So the fine folks at the SANS Internet Storm Center have noticed the PNRP traffic coming from new Vista boxes and posted about it in the diary. I am hopng that any publicity is indeed good publicity and that this helps more developers discover PNRP.
|
-
It has been a few months since my last posting, but I wanted to post some great news. PNRP is in Windows Vista Beta 1. It is there and it is beautiful. We have added some refinements to the message flows, tweaked some packets and made countless improvements in the code. We also have some awesome features in there like Extended Payload, which allows you to associate up to 4k of arbitrary data with a name that can be retrieved in the resolve (think of publishing the name 0.Halo2 with payload info of “14 players in map, 2 openings, player level is 7, map is ___, next game in 10 minutes, etc” and enumerating for the name. You could choose the best endpoint without ever connecting). We added a new resolve-only mode where the stack will go into a sort of silent mode where you can resolve for names without having one published yourself (nice to reduce idle bandwidth use). But perhaps the coolest new feature is GetAddrInfo integration. You read right – GetAddrInfo. If you pass what we call a PeerHostName (basically an encoded form of classifier.authority.pnrp.net) to GetAddrInfo, it will be resolved through PNRP instead of DNS. This means that existing apps can do PNRP resolves without any code change. Basically, think of starting up Terminal Server on your home box, register a name in the global cloud via something like netsh, and suddenly you can term serv into the box without DynDNS or any of that stuff. To convert some normal peer names into PeerHostNames, go into netsh in a cmd window, get into the “p2p pnrp peer” path and try out the convertname helper.
The other thing we did is we setup a service called PNRP Auto Registration (pnrpauto) that is automatically publishing a PNRP name. We did this so that the PNRP cloud would be as big as possible for testing purposes in the betas. We are going to disable this service before RC1, but then we are really excited to get a lot of good data and make sure that the protocol is as good as it can be. If, for some reason you really want to turn off the service, you can do so with the “net stop pnrpauto” command or through task manager.
There is some other really great stuff coming out in B2 that I am dying to talk to you all about, but I don’t want to jinx it yet (it is bad luck around here to mention something before it is in the main builds) but I think you will be VERY happy to see it.
|
-
I have been receiving some questions around PNRP's bandwidth use recently so I thought I would post some info here. The main question I have been getting is about the nature of the bandwidth use. PNRP is a distributed system, and as such, all nodes shoulder some of the burden for the entire system. When you first start the PNRP stack, it registers a name in the global PNRP cloud to bootstrap you in. From then on, you will have some bandwidth used to support the system. The majority of PNRPbandwidth is for processing resolution requests. These requests function by an initiating node sending a resolution request to the neighbor it knows that is closest to the target of the resolution in our address space. That hop will pass it on to a closer node and the so on until it reaches the target. These intermediary nodes make up what we called the hop list. The number of hops needed to reach a target is log(n) where n is the number of names registered in the cloud. Given that log(n) nodes are involved in any given resolution, that makes the probability that any given name will be part of the hop chain log(n)/n. If R is the average number of resolves performed by each node and N is the average number of names / node, then the number of resolves that a name participates in should be log(n)*R/N. If you now want to calculate the amount of traffic per node (as opposed to name, which we just calculated), you need to multiple by the number of names published on that node. If you instead consider that number to be the ratio of the number of names you publish to the average (N in the equation above) and call this number Z, we get log(n)*R*Z. This is interesting as this shows that the traffic consumption of a given node is logarithmically related to overall cloud size, linearly proportional to average resolve rate and linearly proportional to the ratio of names you publish relative to the average. That basically means the bandwidth is a function of how much it is used and how much you use it. There are some other bits of traffic in PNRP as well, but they are smaller terms and a little less interesting. The next question that will probably occurr to you is "Thats a very cute equation, Noah. Now give me a number in bps." Unfortunately, I can't really do that. As you can see from the equation, PNRP's traffic is dependant on a lot of things which are not all predictable. The particularly difficult one to calculate is the number of names registered on a machine. That is a function of how many LH features use PNRP (answer being several), how popular those features are, how many 3rd-party apps depend on PNRP, and how popular those are, and how heavily both those apps and features are used. My guess is that it will be roughly 500 million names in the cloud after a year and probably about 10 names per
|
-
One of my coworkers recently showed me a cool freeware program that adds a rather impressive sidebar to XP. I have been playing with it for a few weeks now and cannot recommend it enough. Check out http://www.desktopsidebar.com/.
|
-
I have been wrestling with a question that I thought I would bring out to the rest of the world. In PNRP today, we have three scopes in which you can register or resolve a name; the global scope which includes all machines in the world, the site scope which mirrors the IPv6 concept of local site (usually within a company) and the link-local scope which represents all machines connected on a link. We have heard from a lot of developers that the link scope is very hard to use as every machine has a different link-cloud name (since the clouds are named after the interface) and because it is confusing regarding which one to use if there are multiple interfaces. Furthermore, IPv6 has deprecated their concept of site-scope, so it is unclear what should be done with that scope. Thus my question for the PNRP users out there is what scopes would be useful to you? My current favorite idea is that site goes away (it never seemed to be used much anyways), individual link clouds remain for power users, but that we add a new keyword that can be used in place of a cloud name called something like 'ALL-LINK.' It would mean to perform the register or resolve in all of the link clouds. This would probably simplify life for 95% of use cases. Does that sound helpful?
|
|
|
|
