I’m going to run N nodes on a device, and they are going to
have to discover each other, and also discover a bunch of other nodes
out there on the local network. I can use UDP for local discovery as
well as remote discovery. It’s arguably not as efficient as using, e.g.,
inproc transport, but it has the great advantage that the exact
same code will work in simulation and in real deployment.
If I have multiple nodes on one device, I clearly can’t use the IP address and port number as the node address. I need some logical node identifier. Arguably, the node identifier only has to be unique within the context of the device. My mind fills with complex stuff I could make, like supernodes that sit on real UDP ports and forward messages to internal nodes. I hit my head on the table until the idea of inventing new concepts leaves it.
Experience tells us that WiFi does things like disappear and reappear while applications are running. Users click on things, with interesting results like changing the IP address halfway through a session. We cannot depend on IP addresses, nor on established connections (in the TCP fashion). We need some long-lasting addressing mechanism that survives interfaces and connections being torn down and then recreated.
Here’s the simplest solution I can see: we give every node a UUID, and we specify that nodes, represented by their UUIDs, can appear or reappear at certain IP address:port endpoints, and then disappear again. We’ll deal with ...