I have a client program running on Unix which creates a socket and connects to a server program running on a Windows machine, then starts performing operations which produce constantly changing double values. I use a timer, and every 5 milliseconds I call a function which takes whatever my value is at that time, converts it to a string, and sends it to the second computer. The server program receives the value from the client and prints to the screen.

The client and server successfully connect, and initially the sending and receiving works. But after a short time, the server's print messages to the screen slow down, and then the messages showing the new values stop altogether.

On the client side program, here's the function I call to connect to the server:

Doesn't this just mean you have a stream input somewhere you are not reading from properly?

Hmm, that might be it, I would hope not though. I'm not the one who was responsible for programming the module that deals with generating the data, just the part that dealt with transferring it to another networked computer. There are about 15 source files involved with those parts of the code I didn't work on, so finding a flaw there would be an epic, painful chore.

You can use fcntl() to set a socket "nonblock" and then run some kind of of very brief pause in your server's for( ;; ) loop. Most servers have to deal with multiple connections, which I'm assuming is done one of three ways:
- via select()
- with multi-threading
- using the loop I just described.
Although you don't have to, it may shake something out of a tree. The timed delay may be needed to prevent recv() from dominating the processor in an infinite loop. The timed delay can also make a difference in the successful reception of information, for one strange reason or another.

I honestly don't know if this will make a difference with tcp sockets, but if you're desperate it's a simple trick to try.

You could do some printf() debugging in the loop you already have as well.

> you get an error.
Yes, something like EAGAIN
As in nothing here at the moment, try again later.

This would be a soft error which wouldn't cause the program any particular difficulty if it's all set up to use non-blocking streams.
Other errors of course you could deal with in the appropriate manner.