schweini has asked for the wisdom of the Perl Monks concerning the following question:

dear monks,

I'd like to try to make a script of mine reeeeaaly easy to deploy and configure, by allowing it to automatically figure out where its server is located, connecting to a certain port on that server, identify itself by using the client's IP (or something), get the matching configuration via the connection, and start up.
I've got a problem with the first step. How can i elegantly 'find' a server? The obvious solution would be to ping all machines on the subnet, try to connect to the specified port, and if that is successful, assume that that machine is the server. Is there a more elegant way to do this? Maybe using broadcast packets or something?

Thanks,

-schweini

Replies are listed 'Best First'.
Re: server 'autodiscovery' on a LAN
by sgifford (Prior) on Nov 24, 2005 at 03:37 UTC
    A broadcast UDP packet would be very easy to do; have your server listen on a particular UDP port for service requests, and when it receives them send a unicast reply with the information needed to connect. Broadcast packets usually aren't routable, so you'll have to make sure the server is on the same network segment as the client. A related idea would be to use multicast, which might put a slightly lower load on your network if it's happening frequently.

    Another thought: if the clients pick up their information from a DNS server you have control over, put a record in their default domain pointing to the server. This is similar to how Microsoft's "proxy auto-discovery" works. It's more efficient and survives routing across subnets, but requires more control over the client.

[reply]
Re: server 'autodiscovery' on a LAN
by NetWallah (Canon) on Nov 24, 2005 at 05:06 UTC
    Your problem description fits the model that BootP/DHCP client/servers use. The DHCP client "Discovers" the server via UDP broadcast. The server, if so configured, can recognize the Mac address of the client, and return client-specific/custom configuration information.

    The protocol allows for customized "DHCP Options" that can be used to pass information to applications, suc as the one you are considering. This would allow the app to "discover" the server, but that discovery happens when the client gets/renews its IP address.

    To research this, please google "DHCP Options".

         "Man cannot live by bread alone...
             He'd better have some goat cheese and wine to go with it!"

[reply]
Re: server 'autodiscovery' on a LAN
by Corion (Patriarch) on Nov 24, 2005 at 07:13 UTC

    My guess also goes in the direction of autodiscovery via DNS. This method is called "zeroconf", and has been branded "Rendezvous" by Apple and then rebranded by Apple as "Bonjour". CPAN has Net::Rendezvous, which implements a convenient method of autodiscovery on the client side.

[reply]
Re: server 'autodiscovery' on a LAN
by idsfa (Vicar) on Nov 24, 2005 at 20:32 UTC

    You are looking for UPnP ("Universal Plug 'n' Play"), which involves an exchange of UDP multicast SOAP messages. It is specifically designed for this task ... being able to ask the local network for available servers and any information they care to send. As an example, ReplayTV uses this protocol to autodetect other players on your LAN, so that you can stream within your house.

    Though I didn't see it on CPAN, a quick google yielded PerlUPnP at sourceforge.

    use UPnP::ControlPoint;

  my $cp = UPnP::ControlPoint->new;
  my $search = $cp->searchByType("urn:schemas-upnp-org:device:TestDevi
+ce:1", 
                                 \&callback);
  $cp->handle;

  sub callback {
      .
      .
      .

    [download]
    The intelligent reader will judge for himself. Without examining the facts fully and fairly, there is no way of knowing whether vox populi is really vox dei, or merely vox asinorum. — Cyrus H. Gordon
[reply]
[d/l]
Re: server 'autodiscovery' on a LAN
by matija (Priest) on Nov 24, 2005 at 08:48 UTC
    I'm a bit confused by your description. Are you saying the machine on which the script is running is or isn't "it's server"?

    If the script runs on "some machine" out on the internet, needs to connect to the central server to get a configuration for this script instance.

    Solution: the server should have a fixed name, and a simple DNS lookup will allow you to connect to the correct machine, even if you have to subsequently move it to a different IP. The very act of connecting to the server will tell the server what the client's IP is.

    If the machine on which the client runs is "unconfigured" (doesn't even have an IP yet), you're much better off running DHCP client (or bootp client) or some other program which is specificaly written for getting and configuring an IP number than you'd be writing one on your own.

[reply]
Re: server 'autodiscovery' on a LAN
by schweini (Friar) on Nov 24, 2005 at 19:00 UTC
    Thanks to everybody who pointed out that autodiscovery via DNS would be an option, but even relying on the fact that DNS is up and running isn't an option, since one of the reasons i want to do this is that if the main server is unavailable, some 'grunts' can simply plug in a spare server, restart the program on the client machines, and my program will simply find the new server, reconfigure itself, and go on doing what it was doing (a Point of Sale in this case).
[reply]
A reply falls below the community's threshold of quality. You may see it by logging in.

Back to Seekers of Perl Wisdom