-1

The situation is as follows. I want to have an application running on a server. All of the desktops in the company has to connect to it. But I do not want the IP address of the server to be hard coded into the desktop apps. Rather I want that the server be able to announce itself by some broadcasting mechanisms. The desktop apps would be listening for such a message and hence gets to know the IP address of the server and can then connect to it

How can I do it ? Do I need to need to use multicast ? How far the multicast messages go upto ? How can the desktop apps listen to multicast data ?

1 Answer 1

1

The most common method for this is to use regular ordinary DNS. Your company probably has its own domain name; possibly an internal one; just add a subdomain under it – myapp.internal.example.com or myapp.corp or something such – and point at your server's address.

myapp.<domain>.         A       10.0.0.5
myapp.<domain>.         AAAA    2001:db8::123:4

(After all, it's a server, its IP address isn't likely to change weekly. And when it does change, all you need to update is the subdomain in DNS.)

You can make it more advanced and use SRV records instead of direct A/AAAA address records. For example, the XMPP chat protocol uses SRV records to locate servers for a domain, which can be multiple with different priorities:

chat1.<domain>.         A       10.0.0.4
chat2.<domain>.         A       10.0.0.7

                                ; priority, weight, port, hostname
_xmpp._tcp.<domain>.    SRV      0 0 5222 chat1.<domain>.
_xmpp._tcp.<domain>.    SRV     10 0 5222 chat1.<domain>.

This is more complex for the apps as they now need some logic to sort the returned records by SRV priority and then by weight, but it might give some advantages such as being able to add slower "backup" servers.


If for some reason that's not acceptable, you can try one of the existing multicast-based service discovery protocols. (Some of them combine name resolution and service discovery into one; others keep it separate.)

  • Apple and various Linux distributions use Bonjour/Avahi aka mDNS ("Multicast DNS") combined with DNS-SD for both general service discovery and local name resolution;

  • Microsoft prefers the UPnP-based SSDP, except when it prefers WS-Discovery instead. It used NetBIOS in the past. All are documented under Function Providers.

  • (Some programs decide to just broadcast UDP datagrams saying "I'm here!" in their own custom format. This doesn't work well.)

There are usually both OS-provided APIs and third-party libraries to look up specific services using the corresponding discovery protocol.

If you're going to implement something yourself, each OS also provides functions to join a multicast group and to receive messages anyone sends to that group. IP multicast should work by default within a broadcast domain, but often needs to be configured to pass routers.

1
  • One thing I forgot to mention is that the server has to be within a corporate's internal network. I do not want to have the server in public domain. If its in local domain, even then there has to some registry that would have to resolve the name which lot of corporates may not have, or the hosts file has to be updated. Note that the client side software also belongs to me but the server's IP address can keep changing because of DHCP. Hence I thought clients could multicast and get the server address when they booted and server can multicast when it reboots and inform its IP address.
    – Raks
    Jul 2, 2014 at 13:30

Not the answer you're looking for? Browse other questions tagged .