Peer to Peer Series Part 4: Resolving Peer Names Asynchronously
- Posted: Sep 18, 2009 at 5:06 AM
- 11,897 Views
- 2 Comments
Loading User Information from Channel 9
Something went wrong getting user information from Channel 9
Loading User Information from MSDN
Something went wrong getting user information from MSDN
Loading Visual Studio Achievements
Something went wrong getting the Visual Studio Achievements
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();
try
{
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;
DisplayResults();
}
}
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:
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.
Follow the Discussion
Oops, something didn't work.
What does this mean?
Following an item on Channel 9 allows you to watch for new content and comments that you are interested in. You need to be signed in to Channel 9 to use this feature.What does this mean?
Following an item on Channel 9 allows you to watch for new content and comments that you are interested in and view them all on your notifications page.sign up for email notifications?
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
close