1

I have been working on a local LAN service which uses a multicast port to coordinate several machines. Each machine listens on the multicast port for instructions, and when a certain instruction is received, will send messages directly to other machines.

In other words the multicast port is used to coordinate peer-to-peer UDP messaging.

In practice this works quite well but there is a lingering issue related to correctly setting up these peer-to-peer transmissions. Basically, each machine needs to announce on the multicast port its own IP address, so that other machines know where to send messages when they wish to start a P2P transmission.

I realize that in general the idea of identifying the local IP is not necessarily sensible, but I don't see any other way-- the local receiving IP must be announced one way or another. At least I am not working on the internet, so in general I won't need to worry about NATs, just need to identify the local LAN IP. (No more than 1 hop for the multicast packets is allowed.)

I wanted to, if possible, determine the IP passively, i.e., without sending any messages. I have been using code that calls getifaddrs(), which returns a linked list of NICs on the machine, and I scan this list for non-zero IP addresses and choose the first one.

In general this has worked okay, but we have had issues where for example a machine with both a wired and wifi connection are active, it will identify the wrong one, and the only work-around we found was to turn off the wifi.

Now, I imagine that a more reliable solution would be to send a message to the multicast telling other machines to report back with the source address of the message; that might allow to identify which IP is actually visible to the other machines on the net. Alternatively maybe even just looking at the multicast loopback message would work.

What do you think, are there any passive solutions to identify which address to use? If not, what's the best active solution?

I'm using POSIX socket API from C. Must work on Linux, OS X, Windows. (For Windows I have been using GetAdapterAddresses().)

Community
  • 1
  • 1
Steve
  • 8,153
  • 9
  • 44
  • 91
  • If you examine the Ipv4Metric value for each, does that give you a indication of the preferred interface? If not, then as far as I know (in Windows at least) the OS makes it's own decision about which to use. Can you not just arbitrarily bind to one of them (and announce that one)? – Geoff Oct 14 '11 at 20:02

2 Answers2

0

Your question about how to get the address so you can advertise it right is looking at it from the wrong side. It's a losing proposition to try to guess what your address is. Better for the other side to detect it itself.

When a listening machine receives a message, it is probably doing do using recvfrom(2). The fifth argument is a buffer into which the kernel will store the address of the peer, if the underlying protocol offers it. Since you are using IP/UDP, the buffer should get filled in with a sockaddr_in showing the IP address of the sender.

Jeff Allen
  • 1,391
  • 13
  • 19
0

I'd use the address on the interface I use to send the announcement multicast message -- on the wired interface announce the wired address and on the wireless interface announce the wireless address.

When all the receivers live on the wired side, they will never see the message on the wireless network.

When there is a bridge between the wired and the wireless network, add a second step in discovery for round-trip time estimation, and include a unique host ID in the announcement packet, so multiple routes to the same host can be detected and the best one chosen.

Also, it may be a good idea to add a configuration option to limit the service to certain interfaces.

Simon Richter
  • 28,572
  • 1
  • 42
  • 64