tags:

views:

301

answers:

1

I can't use Peer Name Resolution Protocol on our network because our server farm's routers won't support IPv6.

So, I'm attempting to implement my own PeerResolver using a database.

  • The Register method inserts a row with the meshId, endpointUri, and list of IP addresses in the database along with a created date, and returns a newly created row guid as the registration id.
  • The Unregister method deletes everything from that Guid.
  • The Update method updates the aforementioned information.
  • My Resolve method currently IGNORES the maxAddresses parameter and returns all the information in the database for that meshId.

It's working pretty well as a proof-of-concept, but since the documentation is basically non-existant, I'm having a hard time deciding how to manage things. For instance:

  • What to do about the maxAddresses parameter. In my testing it usually seems to get called with a value of 3. Why 3? Which 3 should I return? What happens if the 3 I return are all unavailable but there are other addresses that are? Will it try again? And then do I need to ensure that a different 3 are returned when it retries? And how should I do that, randomly? Or do I need to have some information in the database about how a node is connected to other nodes and then return ones that are geographically close?
  • If an application stops peacefully, it will call Unregister, but this obviously doesn't always happen. How do I manage cleanup?
  • The documentation for all the timeout variables seem to indicate that I should throw a TimeoutException if the limit is reached without the command doing what it's supposed to. I can see how this would be important if you were trying to connect over a network to a peer resolution service (like PNRP) but since I'm using my local database, should I just ignore those values?
  • The documentation for the CanShareReferrals property and the PeerReferralPolicy enumeration give very obvious descriptions of the values that you could surmise from the names of the property and enumeration members themselves, but offer absolutely no insight into what would factor into choosing one over another.

I would love it if there was someone out there with a lot of WCF experience who could shed some light on these issues.

A: 

As documented on MSDN Microsoft's Peer Name Resolution Protocol uses Teredo tunnelling to solve the IP6/IP4 access issue.

Just allow Teredo tunnelling for the server farm, it just works

TFD
The question is "How to implement a WCF NetPeerTcpBinding PeerResolver", not "How to AVOID implementing a WCF NetPeerTcpBinding."
David
Based on "I would love it if there was someone out there with a lot of WCF experience who could shed some light on these issues." I answered! We spent ages trying to make our own PR (against good advice) and in the end we just used Teredo
TFD
That information is helpful - thanks! It's very frustrating that Microsoft provides this abstract base class that practically screams "Implement me!" with basically zero information on best practices for an implementation.
David