winsock recv on peer hard close

[abhijitpai05]

I have a query regarding the behaviour of winsock recv function.

I am using:
socket - connection-oriented(TCP)
calls - blocking type.

If the sender does a send() operation & immediately performs hard close of the socket, can the receiver get the data if it has called a recv() operation OR will it get WSACONNRESET error code?

What would be the case if instead of recv() the reciever is using select i/o model? Will the event for read be received first OR for the exception?


Thanks a lot...

[TheCPUWizard]

It depends in part on the size expected by the receive and the amount of data transmitted by the send....

Also *some* TCP/IP stacks have a race condition that may come into play.

What is the use-case where a client would to the send() and immediately close???

[MikeAThon]

The recipient which is blocking on recv() will see recv() return with a filled-in buffer and the returned value of recv() will return an int with the number of bytes in the buffer. It will not somehow get a WSACONNRESET error code. If you think for a moment, this would not be possible anyway: the call to recv() did not return SOCKET_ERROR, which would otherwise be your signal to call GetLastError() and find out the error of WSACONNRESET.

On the next call to recv(), recv() will return a value of 0, indicating that the connection has been closed.

Mike

PS: In answer to a question from TheCPUWizard, it was common in HTTP/0.9 and HTTP/1.0 for the server to send a response and immediately close the connection. It was not until HTTP/1.1 that the idea of persistent connections became widespread.

[TheCPUWizard]

Mike,

Your points are valid, but to explain my reading of this.

1) Client Calls Connect()
2) Client Calls Send()
3) Client does a "hard" Close [immediate termination of all operations on the port

Under this scenario, there are some possibilities..

a) The server may not have even Accepted the connection
b) The connection has been established but the port is shutdown BEFORE all of the bytes have been transmitted.
c) The bytes have been transmitted, but an error occured, so the server there will be an attempt to NACK and retry...on a closed port...

The common server responds and does a "soft" closes, is a common, reliable scenario, but is distinctly different.

[abhijitpai05]

thanks a lot for the replies....

I tried with writing simple programs (server, client) using ACE.
I executed 3 different scenarios to understand the behaviour of recv function.

Consider the connection is establishement pre-condition that is satisfied.

1. Server does a send() of n bytes immediately followed by close(), then in the Client I execute recv() for n bytes.

result: The client gets all the n bytes of data in the first call to recv(), & 0 bytes in the next call to recv() indicating socket is closed from the server end.

2. Client does a recv() (blocking call) for n bytes, then Server does a send() of n bytes and exits without calling close() (hard close).

result: The client does receive all the n bytes of data sent by the server, & in the next call to recv() it gets -1, with GetLastError() returning WSACONNRESET.

3. Server does a send() of n bytes, and exits without calling close() (hard close), & client does a recv() for n bytes.

result: The client does not receive any of the n bytes of data sent by the server, instead it gets -1, with GetLastError() returning WSACONNRESET.


From 2. & 3. it looks like in case of hard close it matters whether recv() has been called before the connection is reset.

But I am unable to come to any conclusion, why recv() called after a hard close (case 3.) is failing to receive the data, whereas the one called before the hard close (case 2.) is able to receive.


Mike, TheCPUWizard can you please help me to reach some conclusion on this..


thanks a lot...


Abhijit