Why is System.Net.Sockets.Socket.AcceptAsync bundled with ConnectionReset after a long inactivity?

Question

It looks like when you call Socket.AcceptAsync with a valid SocketAsyncEventArgs and set up the SocketAsyncEventArgs.Completed event accordingly, and the connection will not be accepted for a very long time, as it just drops the connection. Although my Socket.ReceiveTimeout and Socket.SendTimeout are null.

I am not sure how to set a timeout for receiving connections and even if it is a good idea. Does anyone have a workaround and maybe some information on why this is the default behavior?

I sent a bug report to Microsoft Connect to find out if they have any arguments in favor of why the waiting period is unstable. Sometimes it ends in five minutes, and sometimes more than two hours.

Answer 1

After playing around with this a bit, I found that a single SYN → SYN-ACK → RST sequence would raise the SocketAsyncEventArgs.Completed event and cause the SocketAsyncEventArgs.SocketError property SocketAsyncEventArgs.SocketError become SocketError.ConnectionReset . This seems to be the expected behavior, but it is definitely good and should be better documented.

Any port that scans your server and performs a semi-open scan of the SYN type generates similar traffic and causes the same problem. To prevent denial of service vulnerabilities in the software, you need to work with this special condition.

Answer 2

Perhaps this may help: Socket issue: TcpClient.GetStream with ReceiveTimeout throws Exception and connection status become false

If the socket expires, you can also send it to saved packets every few seconds (minutes).

You can also monitor the connection using Netstat -an | findstr / i "PORT #". You can find information about this at: TCP Connection Status and Netstat Output

I hope this helps you solve your problem.