Reputation: 9906
It appears that when you call Socket.AcceptAsync
with a valid SocketAsyncEventArgs
and have the SocketAsyncEventArgs.Completed
event rigged properly and no connection is accepted for a very long period of time that it just resets the connection. Though, my Socket.ReceiveTimeout
and Socket.SendTimeout
are both zero.
I'm unsure of how to set the timeout for accepting connections and even if it's a good idea at all. Does anyone have a workaround and perhaps some information as to why this is the default behavior?
I filed a bug report on Microsoft Connect to see if they have any reasoning behind why the timeout period is unstable. Sometimes it times out in five minutes and other times more than two hours.
Upvotes: 8
Views: 1878
Reputation: 9906
After playing around with this for a bit I have found that a single SYN -> SYN-ACK -> RST sequence will raise the SocketAsyncEventArgs.Completed
event and cause the SocketAsyncEventArgs.SocketError
property to become SocketError.ConnectionReset
. It appears this is expected behavior but it's definitely a gotcha and should be documented better.
Anyone port scanning your server and doing a half-open SYN type scan will generate similar traffic and cause the same problem. To prevent denial of service vulnerabilities in the software, one should be handling this special condition.
Upvotes: 4
Reputation: 2020
Maybe this could help: Socket problem: TcpClient.GetStream with ReceiveTimeout throws Exception and connected state become false
If the socket times out, you could also send it keep alive packets every few seconds (minutes).
You could also keep an eye on the connection using Netstat -an | findstr /i "PORT#". You can find information about that at: TCP Connection States and Netstat Output
I hope that helps track down your problem.
Upvotes: -1