Problems with recv and timeouts

Question

1) Is there a difference of the meaning of return values of sockets that are blocking and non-blocking? Sometimes recv() returns 0 even select() succeded before AND the peer on the other side did not close the half side of the connection as the documentations states. Is that true?

From the docs of osx and win: " For TCP sockets, the return value 0 means the peer has closed its half side of the connection."

2) Question to blocking sockets: On a blocking socket I expected SO_RCVTIMEO and SO_SNDTIMEO have a set default value like 30 seconds (checked with getsockopt). Why are they set to 0 though?

score 1 · Answer 1 · answered Jul 13 '13 at 12:27

1) Is there a difference of the meaning of return values of sockets that are blocking and non-blocking?

No. There is however a difference in the possible errno/WSAGetLastError() values, in that non-blocking mode adds EAGAIN/EWOULDBLOCK to the possibilities.

Sometimes recv() returns 0 even select() succeded before AND the peer on the other side did not close the half side of the connection as the documentations states. Is that true?

No, that isn't true.

From the docs of osx and win: " For TCP sockets, the return value 0 means the peer has closed its half side of the connection."

Correct. Nothing to do with blocking or non-blocking. Nothing there to suggest the confusion in your question.

2) Question to blocking sockets: On a blocking socket I expected SO_RCVTIMEO and SO_SNDTIMEO have a set default value like 30 seconds (checked with getsockopt).

Your expectation is incorrect. By default they are both zero, meaning infinite.

Why are they set to 0 though?

Because that's the default value. By default there is no timeout.

So I abort the connection if recv() returns 0 where I actually expect still some data? — HelloWorld, Jul 13 '13 at 16:19
No, you *close* the connection if recv() returns zero. There will never be any more data on it. — user207421, Jul 13 '13 at 23:46

Problems with recv and timeouts

1 Answers1