Loading user information from Channel 9

Something went wrong getting user information from Channel 9

Latest Achievement:

Loading user information from MSDN

Something went wrong getting user information from MSDN

Visual Studio Achievements

Latest Achievement:

Loading Visual Studio Achievements

Something went wrong getting the Visual Studio Achievements

Peer to Peer Series Part 4: Resolving Peer Names Asynchronously

5 minutes, 27 seconds


Right click “Save as…”

In Part 4 of the Peer to Peer Series, I modify the Resolve program to find Peer Names using the asynchronous methods.  Below is a very simple example of using the ResolveAsync method:

PeerNameResolver resolver = new PeerNameResolver();
 resolver.ResolveCompleted += new EventHandler<ResolveCompletedEventArgs>(resolver_ResolveCompleted);
 resolver.ResolveAsync(new PeerName(classifier, PeerNameType.Secured), Guid.NewGuid());
catch (PeerToPeerException ex)
 // There are other standard exceptions you can also catch - see docs
 Console.WriteLine("PeerToPeer Excpetion: {0)", ex.Message);
static void resolver_ResolveCompleted(object sender, ResolveCompletedEventArgs e)
 if (!e.Cancelled && e.Error == null && e.PeerNameRecordCollection != null)
 records = e.PeerNameRecordCollection;

There is also a ResolveProgress event you can also wire up.  As the name implies, it will fire periodically to indicate the progress being made in resolving the Peer Name.  It was not overly useful when resolving a Peer Name that had a small number of results, but your mileage may vary.

The one thing that is also a “brute force” implementation in the demo code is how I pass a Guid.NewGuid() into the ResolveAsync method.  The Guid is being used as the UserState parameter in the method, and can actually be any Object. In a real implementation where you may have multiple ResovleAsync requests in-flight at any one time, you would want to implement a tracking system using this UserState parameter so  you could match up the corresponding ResolveCompleted event with the correct initiating request.  The ResolveCompleteEventArgs parameter contains the UserState used to initiate the request, so the matching is pretty straightforward.  I did not go the extra mile and implement that since the demo only fired a single ResolveAsync request.  You cannot pass in a null UserState object, so I went with a simple Guid for no particularly good reason.

Other documentation for PNRP:

Download the Demo Code


Follow the discussion

  • Oops, something didn't work.

    Getting subscription
    Subscribe to this conversation
  • Dennis A. LangePeerReaper Networking Is A Tricky Thing

    Your demo points out a symptom I am experiencing... On a single link-local network, I am experience 10+ seconds resolve times... Not always, but they do seem to occur... Your example also demonstrates a resolve time of >10 sec, even though you mention all machines are on a single network. I assume there are settings to fine tune. I plan to use resolve as a sort of user sign on, and these response times would not fit into the plan.


  • When using PNRP out of the box, I am not sure if there is a way to shorten that resolve time.  However, you could try building your own customer resolver.  There is an example of that provided in the WCF SDK sampeles.  That would be a lot faster but would require you to host a resolving service somewhere.

Remove this comment

Remove this thread


Comments closed

Comments have been closed since this content was published more than 30 days ago, but if you'd like to continue the conversation, please create a new thread in our Forums, or Contact Us and let us know.