Create a Windows (win32) service discoverable across the network

Question

In short: How to reliably discover a server running somewhere on a (presumably multi-segmented) local area network with zero client configuration

My client application has to locate the server application without knowing the server IP address. It has to work on a local LAN that may be split into segments with hubs or other switching devices.

I already have a working solution, but it is a bit cumbersome to get it working on multi-segment networks. It works as follows:

When the client starts up, it sends UDP broadcasts on its own network segment. If the server is running on the same segment, it works without any issues - the server responds with the appropriate messages.

If the server and client are running on networks separated by a hub / switch that won't forward UDP (the most likely case), then I have a server instance running on each segment, and they forward client requests to each other via TCP - but I need to configure this for the server instances (simple, but still a pain for tech support.) This is the main problem that I need to address. There are sites where we have hundreds of clients running on 5 or 6 separate segments.

The problems I'm facing: 1. Although my application installer enables the appropriate ports on the firewall, sometimes I come across situations where this doesn't seem to happen correctly. 2. Having to run multiple server instances (and therefore configure and maintain them) on hub/switched networks that won't forward UDP

Finally I need a solution that will work without maintenance on a minimal Windows network (XP / 2000 / Vista) that probably doesn't have Active Directory or other lookup services configured.

I don't want to tag on any runtime stuff for this - should be able to do it with plain VC++ or Delphi.

What approaches do commercial apps usually take? I know that SQL Server uses a combination of broadcast and NetBEUI calls (I may be wrong about this).

Thanks in advance.

Answer 1

If you have domain server, I would go with small service on it. You can connect with other services to it and use it as distribution point.

Why domain server? It is relatively easy to find it's name (DsGetDcName).

Other choices would include DHCP server, DNS server or something of that kind that needs to be filled by maintenance staff anyhow.

Answer 2

You have a few terminology issues:

• Where you say "network segment" you appear to mean "IP subnet". Devices on the same network segment can see the same IP broadcasts.
• Where you say "hub/switch" you appear mean "IP router".
• Where you say "won't forward UDP", the problem is actually "won't forward IP broadcasts".

Once we get past that, you have a few options:

• Your servers could register themselves under a well-known name in DNS, if you have a DNS server that allows dynamic DNS updates. You should probably use a SRV record as specified in RFC2782. The clients then do a DNS lookup to find the server(s).
• You could statically assign your server(s) well-known names in the organisation's DNS, perhaps with a SRV record as with the previous option.
• Your servers could join an IP multicast group, if your routers support IP multicast. The clients then send their initial discovery request as a UDP packet to the (pre-ordained) multicast address.