Have TCP client search for TCP Server

Question

Background

I am using a SparkCore wireless arduino board to connect to a local Node.js server. The server includes a local intranet TCP server that a TCP client programmed onto the SparkCore connects to.

Problem

If I run the server on a different network, the server has a different local IP address. When I do this, I have to reprogram the SparkCore arduino to tell it the new local IP address of the server to connect its TCP client to. This is not ideal for a variety of reasons.

Question

Is there a way to have the client dynamically search for the TCP server or alternatively have the server broadcast to TCP clients in a way that would inform the client of the local IP address to use for the server without initially hardcoding it? I would love to do this in way that did not involve iterating through a bunch of IPs on a specific port to see if a connection is made. That being said, if that's the only way to do this, then so be it.

Answer 1

How is the arduino booting? If it's booting using DHCP, one method would be to provide a customer DHCP option that provided the address of the node.js server. ntp , for instance, can configure itself in a similar way. This has the advantage that the arduino need not be on the same local subnet as the node.js server.

An alternative (slightly disgusting) would be to use an A record within your domain (let's say nodejs.example.com . Configure the local DNS recursive server to explicitly return this value (I am presuming you might have lots of different deployments with lots of different nodejs servers).

A third possibility would be to send out some form of discovery packet, either by broadcast, or better by multicast UDP. Assuming it's on the same LAN, the nodejs server could then reply. Clearly you might need to concern yourself with a rogue server impersonating your nodejs server, and therefore might need to add some security (eg use a shared secret, send a random nonce plus the nonce hashed with the shared secret to the server, the server checks the hash, and replies with the answer, the nonce, plus the answer hashed with the shared secret and the nonce, each of which the client then checks).