WSAECONNRESET recovery
Author
Hi,
I have a problem and I don't know how to solve it:
After a client disconnects (forced by crush or some other cause) the recvfrom call on server fails with WSAECONNRESET.
I know this is caused because the client connection was not properly closed, but I would like to make the server immune to this "client forced disconnect".
Does any one knows how can I avoid this problem ?
Thanks!
You need to handle that particular error, and close the socket and terminate the client data structures you have allocated, just like you would if the client disconnected properly.
Author
I see.
I am using UDP, and I use only one socket on server side. The problem is that I don't know which client has failed. That particular client will be correctly removed after some "timeout" delay.
I'll try to see how it works if I close and reopen the socket in that particular case.
Is it ok to use one socket on server ?
Thanks.
I am using UDP, and I use only one socket on server side. The problem is that I don't know which client has failed. That particular client will be correctly removed after some "timeout" delay.
I'll try to see how it works if I close and reopen the socket in that particular case.
Is it ok to use one socket on server ?
Thanks.
> The problem is that I don't know which client has failed.
Don't you get an IP address from the call to recvfrom() that returns the error?
Also, I don't think you need to close and re-open the socket (although that will work perfectly fine -- I've done it in the past). The socket will return one error per ICMP not reachable message received, but should then go back to return good data from other incoming packets.
Don't you get an IP address from the call to recvfrom() that returns the error?
Also, I don't think you need to close and re-open the socket (although that will work perfectly fine -- I've done it in the past). The socket will return one error per ICMP not reachable message received, but should then go back to return good data from other incoming packets.
Author
I solved the problem and I thought to put here the solution in case anyone else will have it.
Apparently in some windows versions it happens the following "feature":
Quote from microsoft support site:
And the solution (from the same source):
Use WSAIoctl and set the SIO_UDP_CONNRESET control code to false:
Apparently in some windows versions it happens the following "feature":
Quote from microsoft support site:
Quote: CAUSE
If sending a datagram using the sendto function results in an "ICMP port unreachable" response and the select function is set for readfds, the program returns 1 and the subsequent call to the recvfrom function does not work with a WSAECONNRESET (10054) error response. In Microsoft Windows NT 4.0, this situation causes the select function to block or time out.
And the solution (from the same source):
Use WSAIoctl and set the SIO_UDP_CONNRESET control code to false:
BOOL bNewBehavior = FALSE;DWORD dwBytesReturned = 0;if (WSAIoctl(m_Socket, SIO_UDP_CONNRESET, &bNewBehavior, sizeof(bNewBehavior), NULL, 0, &dwBytesReturned, NULL, NULL) == SOCKET_ERROR){ ShowError();} This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement