Take the 2-minute tour ×
Server Fault is a question and answer site for professional system and network administrators. It's 100% free, no registration required.

I can't perform wcf discovery through a network router.

I have a client and server app. When deploying these two apps to any two computers on the same lan it works perfectly. The client app finds the server app and starts communicating. When I move the client to another network, separated by a router, it cannot find the server.

The router is a Cisco Catalyst 3750. I have full permission to change the settings, but I am not sure which settings apply to wcf discovery packets.

My goal is to change the router configuration so that the wcf discovery packet which is broadcast on the client's lan, is rebroadcast through the router to the server's lan.

Can you give any examples of performing wcf discovery through a router? Do you know any router settings I should be looking for?

share|improve this question

migrated from stackoverflow.com Aug 24 '11 at 1:32

This question came from our site for professional and enthusiast programmers.

    
You might want to try SuperUser –  James Aug 19 '11 at 17:26

2 Answers 2

We were able to get WCF discovery working across networks. Basically we had to increase the TimeToLive in WCF to be more than the default of 1. Here is a more detailed explanation from our network consultant:

The standard TTL for the WS-Discovery packets from WCF are 1. By increasing this to a larger number, and enabling sparse-dense PIM on the correct SVIs on layer 3 switch configured as a the RP, multicast routing allows the WS-Discovery protocol to traverse multiple subnets on a larger enterprise level. This will NOT work through NAT, firewall, etc – it will only work between actual routed subnets (though it should work through an IPsec encrypted VTI with properly configured IP and multicast routing protocols).

share|improve this answer
up vote 0 down vote accepted

After much research, I have decided that this is either not possible, or at least totally impractical. By network definitions, the act of broadcast udp through a router would not return any meaningful result.

For example, lets assume I could get the router to rebroadcast the message to all other subnets. I could conceivably get results from 10.0.1.5 on one subnet (lets call this PC1), and 10.0.1.5 on another subnet (PC2). The TCP/IP technology has no way to differentiate them. Furthermore, trying to open a channel to 10.0.1.5 and another channel to 10.0.1.5 would just be silly. So, even though I know that I would get unique results based on my network topology, the router would have no way to prove that.

To make matters worse, the router actually hides PC1 and PC2 ips from me. This is done by the NAT (network address translation) technology. I may have to address 10.3.3.64 to reach PC1, and 10.3.4.64 to reach PC2. Again, my topology does not lead to these obscure numbers, they are quite unique and predictable, but the system cannot prove that.

Conclusion: I have decided to build a "tracker". This is how P2P networks work. All computers will report-in to a known tracker, and clients will ask the tracker for addresses to the servers it desires.

share|improve this answer

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.