Suggested fix on Windows: handle also WSAETIMEDOUT after recv() returns failure

[Tor Lillqvist]

> According to MSDN, WSAETIMEDOUT means the connection has been "dropped":

>  "The connection has been dropped because of a network failure or
>  because the peer system failed to respond."

That is clearly only half a truth, the MSDN doc for SO_RCVTIMEO under
setsockopt() says that

"In Windows 2000 and later, if no data arrives within the period
specified in SO_RCVTIMEO the recv function returns WSAETIMEDOUT, and
if data is received, recv returns SUCCESS."

so that case should also be mentioned on the recv() doc for WSAETIMEDOUT.

But, it also warns that "If a send or receive operation times out on a
socket, the socket state is indeterminate, and should not be used; TCP
sockets in this state have a potential for data loss, since the
operation could be canceled at the same moment the operation was to be
completed." which sounds a bit alarming... MSDN documentation can be
misleading and contradictory at times.

(http://msdn.microsoft.com/en-us/library/ms740476(VS.85).aspx )

> Are you saying that calling recv again after a WSAETIMEDOUT actually
> results in data sooner or later?

At least that is what I saw in my (not very systematic, I admit) test
under gdb... I guess more experimentation is called for.

--tml