Computers on LAN do not consistently receive a UDP broadcast to 255.255.255.255 using boost::asio C++

Question

I am quite new to network programming, but nonetheless I am working on a personal project that requires interfacing between two computers on the LAN.

For all of my networking needs, I am using boost.

Since computers running my software on the LAN do not know one another's IP addresses, the program immediately sends a UDP broadcast to 255.255.255.255. Another computer listens on the port 25566. If a computer receives a broadcast, it replies with another broadcast to ensure that the other connects via a TCP connection in the appropriate manner.

I have a laptop, and a desktop, both running Linux. If I test the code (two instances of the same thing) on the same machine, everything works flawlessly. However, a problem arises when I run one instance on the laptop, and another on the desktop. Two scenarios happen:

The first - I run one instance of the program on the Desktop computer. It sends a "Hello" message to check if another instance is running anywhere else on the LAN. Since there is no other instance running, it receives no response. Several seconds later, after the desktop instance sets itself up, I start an instance of the program on the laptop. The laptop broadcasts a "Hello" message as well. However, this is where the problem kicks in. When the laptop is the one sending the "Hello" message, there is only about a 10% chance that the desktop program (already running) actually receives it. I monitored the network with Wireshark on the desktop machine, and, again, Wireshark only picks up the broadcast from the laptop 10% of the time. However, if I run Wireshark on the laptop that is sending the "Hello" broadcast, Wireshark picks it up every single time.

The second - This is similar to the first, except the laptop runs the program first. I then start the desktop instance several seconds later. However, when the desktop broadcasts "Hello" the laptop receives the broadcast about 95% of the time (in contrast to 10% of the time when the roles are reversed). The laptop then responds with a "Configure" broadcast. The desktop then receives the "Configure" broadcast nearly 100% of the time. I confirmed the 95% receive rate with Wireshark again.

I am certain there is no problem with my program ignoring these packets. However, something is happening in the network where the broadcast packets are ignored or filtered. What I find particularly strange is how the desktop program only receives the "Hello" message 10% of the time in scenario 1, but receives the "Configure" message 100% of the time in scenario 2. If something strange was happening that prevented packets from reaching the desktop, woulden't both of those percentages be roughly equal?

Here is some of the code that I run to setup the necessary sockets:

broadcast_socket = new udp::socket(*ioservice); //Set up the socket that broadcasts the message
listen_socket = new udp::socket(*ioservice); //Set up the socket on port 25565 that listens for a broadcast

//Set up the ioservice...

error_code e1, e2;
broadcast_socket->open(udp::v4(), e1); //Actually open the sockets
listen_socket->open(udp::v4(), e2);

//Do some error code checking...

listen_endpoint = udp::endpoint(ip::address_v4::any(), port); //Get endpoint for port 25566 (listen_endpoint becomes 0.0.0.0:25566 after this call)

listen_socket->set_option(udp::socket::reuse_address(true));
listen_socket->bind(listen_endpoint);

broadcast_socket->set_option(udp::socket::reuse_address(true));
broadcast_socket->set_option(socket_base::broadcast(true));

broadcast_endpoint = udp::endpoint(ip::address_v4::broadcast(), port); //Get the broadcast_endpoint (returns 255.255.255.255)

Here is the code I use to receive broadcasted messages:

error_code ec;
size_t available_bytes = listen_socket->available(ec); //See if data is available
size_t read_bytes = 0;
char buffer[1024];

if(available_bytes > 0 && !ec){
    read_bytes = listen_socket->receive_from(boost::asio::buffer(buffer, (available_bytes < sizeof(buffer) ? available_bytes : sizeof(buffer))), listen_endpoint);

    read_data.append(buffer, read_bytes); //Append to a string for later processing
}

And finally, here is how I send data:

std::string payload = "Some payload stuff goes here";

broadcast_socket->send_to(boost::asio::buffer(payload, payload.size()), broadcast_endpoint); //Broadcasts to the broadcast_endpoint (255.255.255.255) which was determined earlier

So essentially my question is, why does some of my broadcasts not get through?

Thanks

EDIT:

Also, I forgot to mention that each computer receives its OWN broadcast every single time. So I think its a problem with the network, and not my code.

Answer 1

UDP is not guaranteed to deliver. That's part of the properties of the protocol.

The fact that you can observe the behaviour with Wireshark confirms that it has little to do with Boost.

Using 255.255.255.255 is a blunt weapon and it is limited:

Setting all the bits of an IP address to one, or 255.255.255.255, forms the limited broadcast address. Sending a UDP datagram to this address delivers the message to any host on the local network segment. Because routers never forward messages sent to this address, only hosts on the network segment receive the broadcast message.

You can be more targeted by using the subnet mask:

Broadcasts can be directed to specific portions of a network by setting all bits of the host identifier. For example, to send a broadcast to all hosts on the network identified by IP addresses starting with 192.168.1, use the address 192.168.1.255.

This heightens the chance that the router will know where to send the packet (I'm not a network engineer, so I'm not sure about the implementation details).

Enter Multicast Groups:

Unlike broadcast transmission (which is used on some local area networks), multicast clients receive a stream of packets only if they have previously elect to do so (by joining the specific multicast group address). Membership of a group is dynamic and controlled by the receivers (in turn informed by the local client applications).

(source: http://www.erg.abdn.ac.uk/users/gorry/course/intro-pages/uni-b-mcast.html)

This is more likely to fit your application. You'll have to select a good group endpoint depending on the network configuration, so it's slightly more involved.

Yet, you'll have support of all modern router hardware/software to ensure delivery to the interested parties (only).