What is your flags given to recv() ? You can control most of it's handling through those.. If you are using MSG_PEEK, then you have to realize that the message in the socket won't be removed, thus still be there on next read.
If you are using MSG_WAITALL, then it will block the socket queue untill the read is fully satisfied, so since you let your server app terminate, a read might return with EAGAIN or EINTR, and thus terminate the read befor it is completed, this will let what ever is left of the End Of Transmission signal remain in the socket, thus cludging up the recv() call on next read, since the remainder isn't matching what you'd expect as the termination signal.
Quote:
|
Does initialising the API or socket allow the API to buffer input until it's retrieved or something?
|
I havn't got my Unix Network Programming book with me where I am right now, so I can't say for sure, but you might wanna check
errno for EAGAIN, to check for the blocking of the recv() call, or check for ECONNREFUSED to see if the server has terminated the socket.