The program that runs on the other end of the network is a an executable written in C++, running on Linux, that does a very similar thing, but in reverse.
The c++ will do the following: start sending out heartbeat messages on UDP, with a destination port of 31003.
It sets off a receiver thread which does the following:
* polls its local socket (31006)
* sets a flag "x" when there's something to read
* When "x" is set the message is read, and identified as as a heartbeat, and sets global flag "y"
Meanwhile the main execution sits and waits for "y" to be set. When this happens it starts sending out heartbeats... which is what my labview code is waiting for on the other end of the network.
I hope I'm not making this sound more complicated than it should be - each side needs to send and receive heartbeat messages over UDP, but if the other side hasn't started yet, then it seems wrong for the Labview side to crash out. The C++ side seems quite happy to sit there waiting for a message to arrive, waiting on the receive UDP in one thread, whilst sending UDP on the other.
By the way, at the moment the network gear is simply a crossover cable connecting the two machines.