Recv is one of the most commonly used functions in socket programming. Sometimes different values are returned for the blocked Recv, and corresponding error codes for the error values correspond to different States, the following is a brief summary of several common network statuses.
First, blocking the received Recv will sometimes return 0, which only happens when the socket is normally closed.
When the network cable of the device is unplugged, The Recv will not change and will still be blocked. If the socket is switched off during the network disconnection phase, the consequence may be that the Recv is permanently blocked.
Therefore, setsockopt is usually used to set socket timeout for blocked sockets.
When the timeout arrives, Recv returns an error, that is,-1, and the error code at this time is eagain or ewouldblock, The POSIX.1-2001 allows either of the two to appear, therefore, we recommend that you write both the error codes.
If the socket is closed by the other party in the form of linger 0, that is, when the RST is directly sent, the Recv will also return an error with the error code enoent
There is also a common error code in the code, that is, TER ter, which means that the system is forced to return when receiving other interruption signals. If it is not a socket fault, it should continue to receive the error code. However, this situation is very difficult to reproduce. I tried to keep sending signals while using Recv to receive data. This kind of Exception error has been seen by only one of my friends in the vicinity when using write, but it always has a probability. Therefore, as a perfect program, this error must be specially handled.
Common Methods for setting timeout to block Recv are as follows:
While (1)
{
CNT = (INT) Recv (m_socket, pbuf, recvsize, 0 );
If (CNT> 0)
{
// Process data normally
}
Else
{
If (CNT <0) & (errno = eagain | errno = ewouldblock | errno = eintr ))
{
Continue; // continue receiving data
}
Break; // jump out of the receiving Loop
}
}
Recv summary under blocking Mechanism