Before everybody marks this as a dup let me state that I know my fair share of network programming and this question is my attempt to solve something that riddles me even after finding the "solution".

The setup

I've spend the last weeks writing some glue code to incorporate a big industrial system into our current setup. The system is controlled by a Windows XP computer (PC A) which is controlled from a Ubuntu 14.04 system (PC B) by sending a steady stream of UDP packets at 2000 Hz. It responds with UDP packets containing the current state of the system.

Care was taken to ensure that the the 2000 Hz rate was held because there is a 3ms timeout after which the system faults and returns to a safe state. This involves measuring and accounting for inaccuracies in std::this_thread::sleep_for. Measurements show that there is only a 0.1% derivation from the target rate.

The observation

Problems started when I started to receive the state response from the system. The controlling side on PC B looks roughly like this:

forever at 2000Hz {
  send current command;
  if ( socket.available() >= 0 ) {
    receive response;
  }
}

edit 2: Or in real code:

auto cmd_buf = ...
auto rsp_buf = ...

while (true) {
   // prepare and send command buffer
   cmd_buf = ...
   socket.send(cmd_buf, endpoint);

   if (socket.available() >= 0) {
      socket.receive(rsp_buf);
      // the results are then parsed and stored, nothing fancy
   }

   // time keeping
}

Problem is that, whenever the receiving portion of the code was present on PC B, PC A started to run out of memory within seconds when trying to allocate receive buffers. Additionally it raised errors stating that the timeout was missed, which was probably due to packets not reaching the control software.

Just to highlight the strangeness: PC A is the pc sending UDP packets in this case.

Edit in response to EJP: this is the (now) working setup. It started out as:

forever at 2000Hz {
  send current command;
  receive response;
}

But by the time the response was received (blocking) the deadline was missed. Therefore the availability check.

Another thing that was tried was to receive in a seperate thread:

// thread A
forever at 2000Hz {
  send current command;
}

// thread B 
forever {
  receive response;
}

Which displays the same behavior as the first version.

The solution

The solution was to set the socket on PC B to non blocking mode. One line and all problems were gone.

I am pretty sure that even in blocking mode the deadline was met. There should be no performance difference between blocking and non-blocking mode when there is just one socket involved. Even if checking the socket for available data takes some microseconds more than in non-blocking mode it shouldn't make a difference when the overall deadline is met accuratly.

Now ... what is happening here?