Socket problem [Win32, ws2]

[TheSheep]

I've set up a client/server application communicating over a TCP port. Without going into too much detail, the client sends a message, the server replies, the client replies, etc. etc. until the server has sent all its data and transmits a termination message. At this point the server disconnects and the client should do the same.

For whatever reason, the client seems not to receive the final message. Since the socks API is single-threaded I'd expect that the entire packet would be sent before the send() function even returns, so I'm fairly confident the message is actually sent. It's also not a loss or lag problem, since this even occurs over my loopback.

Can anyone suggest why, instead of returning (even if returning an error), the recv() function on the client just hangs on the final message?

[redhead]

Just a thought.. Description of recv() tells you that

If no messages are available at the socket, the receive calls wait for a message to arrive, unless the socket is nonblocking.

Could this be the case, it recieved the End Of Transmission message, but for some reason your recieve loop on the client runs one more time, and here it hangs in the recv() since theres no messages in the socket.

But since you didn't provide any code, it is hard to make any assumption on what is happening.

[TheSheep]

Thanks for the suggestion; I'll certainly look at the possibility but I'd expect it to receive the termination message in that case and respond to it.

Unfortunately it's not exactly easy to post up the code since it's spread between about 5 different modules. As an outline, the server and client are both running timers and checking receiving every 1/2 second, and are 1/4 second out-of-sync with each other (I figured this would be far more practical than some sort of negotiation since the max possible message size is 1KB). Each application receives the message, processes it (which only consists of quick memory I/O) and sends its reply.

I thought maybe there's some feature of the sockets API that I'm missing altogether. This is my first ever sockets program so kinda lends itself to disaster. Does initialising the API or socket allow the API to buffer input until it's retrieved or something?

[redhead]

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.

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.

[TheSheep]

I'm usings flags=0. The only flags supported under Win32 are PEEK and OOB which are no use to me.

I've managed to bypass the problem by using select() to check the readability of the socket but it seems slower.

[QUantumAnenome]

It would be better to use WSAAsyncSelect() and do your recv() calls inside the message loop. That way you don't have to worry about when or if a message has been sent.