Network Discovery via UDP

[mje]

I have a rather amateurish question here, but frankly this is the first time I've ever had to deal with networking so in this respect, I am the amateur.

 

I'm writing an application which will be communicating with deployed targets. The network topology is the client computer is connected to a switch as are one or more targets. Both the client and targets have obtained DHCP addresses from a server by virtue of another connection to the switch. I'm trying to avoid any hard-coded IPs, and similarly don't want to have to burden the user with actually knowing the IPs of all the computers involved, so was trying to do some basic network discovery.

 

So let's have a loop spinning on each target which responds to UDP discovery requests:

 

It sits and waits for a "Hello?" broadcast, and when it gets one, responds with a hearty "Hello!". Yes of course it will ultimately get more sophisticated than that, but let's learn to crawl before we walk, hmm?

 

Now the client computer will come along and send out a UDP "Hello?" broadcast and wait for a bit to see who's out there.

 

This works great when I test them locally on my client machine. I'll note for "Local Port" I'm using a zero value such that the OS just grabs anything that's available. The "Remote Port" in the bottom bit of code is set up to match the "Port" setting for the top bit of code. But when I put the target logic on one of my RT targets, I get nothing. When I debug the target VI it doesn't get the broadcast. So there's something basic about UDP broadcasting I'm not quite getting. Anyone care to offer advice to a noob?

[Bryan]

I'm not 100% familiar with UDP, but I'm wondering about the IP address your client is writing to and whether you're wanting to write to a multicast address (224.0.0.0 to 239.255.255.255).  I don't think that 255.255.255.255 (FFFFFFFF) is a legitimate address to write to for either TCP or UDP.  Or, is that just for your example?

 

If you do multicast, both will need to subscribe to that address (in the range cited above) as Read, Write or ReadWrite.

[mje]

I'm not 100% familiar with UDP, but I'm wondering about the IP address your client is writing to and whether you're wanting to write to a multicast address...

 

Cheers Brian, this put me on the right path. It turns out 255.255.255.255 is a valid UDP broadcast address, but the datagram won't make it beyond the local network, that is it won't make it past the network adapter. So not very useful for most situations. The correct way to do this is to broadcast to an address masked with the compliment of the subnet the adapter is operating on:

 

 

Works like charm.

[ShaunR]

Cheers Brian, this put me on the right path. It turns out 255.255.255.255 is a valid UDP broadcast address, but the datagram won't make it beyond the local network, that is it won't make it past the network adapter. So not very useful for most situations. The correct way to do this is to broadcast to an address masked with the compliment of the subnet the adapter is operating on:

 

client2.png

 

Works like charm.

You might want to take a look at the Transport.lib as well. It has an example of UDP Multicast and some nice features such as encryption, compression, timestamps and payload size (you can use more than 1500 byte payloads on windows and linux).

Edited March 5, 2013 by ShaunR

[LogMAN]

You might want to take a look into the Bootstrap Protocol which is standartized in RFC951 and quite common for such kind of tasks (at least in my business).

This protocol basically uses the UDP broadcast address 255.255.255.255 on port 64 ( I guess ) to request any compatible device. The device will respond on the
port 65 of the broadcaster. The broadcaster is then able to specify the IP-Address and some more parameters of the target device.

[Bryan]

Cheers Brian, this put me on the right path. It turns out 255.255.255.255 is a valid UDP broadcast address, but the datagram won't make it beyond the local network, that is it won't make it past the network adapter. So not very useful for most situations. The correct way to do this is to broadcast to an address masked with the compliment of the subnet the adapter is operating on:

 

client2.png

 

Works like charm.

 

Glad I was able to help!  Actually, I think it was mutual as I think I learned something too.

 

So 255.255.255.255 is only a good address for localhost-type UDP communication then? 

[mje]

So 255.255.255.255 is only a good address for localhost-type UDP communication then? 

 

I'm unclear on this. I've seen reference to 255.255.255.255 being also used as a "down the wire" broadcast address for example when a machine might not have an address. So the 255.255.255.255 address likely makes it past the adapter but everything I've seen so far implies the broadcast stops as soon as it hits a router. I'm going on the assumption by "router" the literature basically means any network hardware beyond an adapter since my initial test failed as soon as the devices were separated by a switch, but this is where my network knowledge starts to wear thin.

 

To all, is it "ok" to listen for replies on the same port as the initial broadcast? The RFC uses distinct broadcast and listening ports, I'm wondering if I should do the same?

[LogMAN]

I'm unclear on this. I've seen reference to 255.255.255.255 being also used as a "down the wire" broadcast address for example when a machine might not have an address. So the 255.255.255.255 address likely makes it past the adapter but everything I've seen so far implies the broadcast stops as soon as it hits a router. I'm going on the assumption by "router" the literature basically means any network hardware beyond an adapter since my initial test failed as soon as the devices were separated by a switch, but this is where my network knowledge starts to wear thin.

 

I use a switch for these kind of broadcast very often and I don't have any trouble with them... The behaviour might however change depending on your device and networking structure (I did never use the broadcast on a local network with server and such stuff...) As for the router itself I'm pretty sure they don't like to see broadcasts...

 

To all, is it "ok" to listen for replies on the same port as the initial broadcast? The RFC uses distinct broadcast and listening ports, I'm wondering if I should do the same?

 

You should use seperate ports in my opinion. I'm not very deep into networking too, but I think it's kind of 'bad style' to use the same port.

Edited March 5, 2013 by LogMAN

[mje]

Just getting into the RFC now:

 

 

The reason TWO reserved ports are used, is to avoid 'waking up' and scheduling the BOOTP server daemons, when a bootreply must be broadcast to a client.

 

Since my replies are never going to be broadcasts it's probably excessive to use two ports.