Client/Server peer-to-peer discovery across WiFi/Domain networks

Question

I'm trying to create a client/server application (with a Windows Phone 7 client and a Windows PC server) that can auto-discover each other on a network without any intervening servers or pre-existing peer network. I've been able to create a prototype client/server implementation using multicast UDP for a simple discovery model. This scheme works well when both machines are configured to use the same WiFi network. However, in cases where the server (PC) is connected via Ethernet to a domain network, the client (WP7) and server can no longer send or receive UDP multicast packets. The two have different Gateway servers configured, but oddly enough, they can still establish a connection over TCP/IP if an explicit IP address of the server is used.

What's the right way for a client/server to auto-discover one another when they are on a network configured in this manner? Is there a standard mechanism for auto-discovery? Is this potentially a network issue or is it something that can be addressed in the application layer?

Any insights would be appreciated.

Answer 1

Multicast UDP is usually not propagated across router boundaries. Consequently the tradition is to use some central server for discovery of peers. When you need to discover a server, things become trickier. In some cases DNS can be used (you can put a custom record to the DNS and the record will reference the server's address). In Active Directory environments you can probably use some AD server to keep similar records.

Answer 2

These are my thoughts, not sure if they are accurate. Doing it the UDP way should be fine, protocols like Totem rely on UDP I guess. UDP is something the network protocols also peg on for auto service discovery.

But when you are dealing with cross domain issues where UDP fails to be reliable, you will have to go with TCP. TCP will ensure reliability but I doubt if it has the ability to do auto discovery.

I think a good way could be to have the server registered with a Naming server like LDAP .. so that the client can then be able to query the LDAP and get the server details. But then this is more me an application layer approach.

I have seen in our product we use Gossip protocol over TCP to to check the heartbeat of the distributed systems.