The situation:
I am working on a senior design project that involves calculating the source of a signal by correlating audio from many devices that are all on the same WIFI network. The devices exchange information using REST apis.
The architecture is master slave, where the master unit will request audio from all of the slave units. Right now, the slave units need the IP of the master unit. Then they say 'hello' to the master unit who stores their IP, location etc in a list.
What I think I want:
I would like the slave units to have some way of automatically discover the master unit's IP. I don't think I really care about security. What is the best way to do this?
Is there an idiomatic way to do this?
I think I might just not have the correct words to google
Solutions I have considered:
1. Assign static IP to all (or just master unit).
- not ideal because it would only work on one router
- not slick
- Master unit listens on hard-coded port and minions post to broadcast IP.
Yes, using a well known port to rendezvous on is the standard way to solve this problem.
I would turn your approach around a bit. There's more minions than masters, so master should do the broadcasting. A minion might send one (or a handful) of broadcasts upon power-on, to encourage an immediate reply from master. But as hours and days go by, the master should be the one primarily responsible for keeping the population in sync.
A minion should remember IP of most-recent-master, and try unicasting to that upon startup.
Consider using a packet format along these lines: {magic_number, version, start_time, num_minions, optional_list_of_minions}
The list of minions would include {ip_addr, time_of_last_transaction}, and would be empty if the list no longer fits within some limited size UDP packet. Minions could detect master reboot by noticing that start_time changed, and would re-connect soon after reboot. Do take care to randomly jitter your delay timers, so we won't see a thundering herd of minions.