1 The following is the information found on the Internet, thank you very much in advance.
Use setsockopt() to control the timeout of recv() and send()
In the process of send() and recv(), sometimes due to network conditions and other reasons, the sending and receiving cannot be expected, and the sending and receiving timeout control is set:
under Linux , it should be noted that the time control structure is struct timeval instead of an integer number ,
int nNetTimeout=1000;//1 second,
//Set the send timeout
setsockopt(socket, SOL_SOCKET, SO_SNDTIMEO, (char *)&nNetTimeout, sizeof(int));
//Set the receive timeout
setsockopt(socket, SOL_SOCKET, SO_RCVTIMEO, ( char *)&nNetTimeout,sizeof(int));
This will not work in the linux environment, it must be defined as follows: struct timeval timeout = {3,0};
//Set the send timeout
setsockopt(socket, SOL_SOCKET, SO_SNDTIMEO ,(char *)&timeout,sizeof(struct timeval));
//Set the receive timeout
setsockopt(socket, SOL_SOCKET, SO_RCVTIMEO, (char *)&timeout, sizeof(struct timeval));
There are two points to note:
1) The fourth parameter of recv() needs to be MSG_WAITALL. In blocking mode, the specified number of data will not be returned unless the timeout expires. Also note that as long as the receive timeout is set, it is also valid without MSG_WAITALL. In the final analysis, the timeout is to prevent your program from waiting there, and only return once after a certain period of time.
2) Even if the waiting timeout value has not expired, but the other party has closed the socket, recv() will return immediately at this time, and return as much data as it receives.
2 Description of the project problem
The client needs to go to the server to pull the log every minute, and the file size is variable. In order to backup the server database, the path needs to be repaired after the server database crashes, so the server needs to be restarted, then the problem is coming. If it is the client sending The server is disconnected when the thread is running, what should I do?
Phenomenon----->The client does not continue to send the thread, but just downloads the thread. The guess is that it may be because the confirmation information from the server is not received, and it is found that it is not after debugging. Later, it was located on the recv function. I tried to set a timeout of 3 seconds, and a new problem occurred, that is, the file was sent indefinitely. Finally, I found out that the reason for the problem is: the set time is too short, so that the file is too large to be sent, and the backup database does not clear this file number, resulting in circular sending. Just set it to one minute.
Come on, Sao New Year. . . . . . .