2011-11-24 9 views
7

Parece que cuando llama al Socket.AcceptAsync con un SocketAsyncEventArgs válido y tiene el evento SocketAsyncEventArgs.Completed amañado correctamente y no se acepta conexión durante un período de tiempo muy largo que simplemente restablece la conexión. Sin embargo, mi Socket.ReceiveTimeout y Socket.SendTimeout son ambos cero.¿Por qué System.Net.Sockets.Socket.AcceptAsync se completa con ConnectionReset después de un largo tiempo de inactividad?

No estoy seguro de cómo configurar el tiempo de espera para aceptar las conexiones e incluso si es una buena idea. ¿Alguien tiene una solución alternativa y tal vez alguna información sobre por qué este es el comportamiento predeterminado?

I filed a bug report en Microsoft Connect para ver si tienen algún razonamiento detrás de por qué el tiempo de espera es inestable. Algunas veces se agota en cinco minutos y otras veces en más de dos horas.

+0

¿Has comprobado qué está pasando en el cable con wireshark o algo así? ConnectionReset debe estar relacionado con un socket conectado, no con un socket de escucha. –

+0

Originalmente había asumido lo mismo y por eso estoy tan confundido con esto. Estoy ejecutando una prueba con el registro de wireshark mientras hablamos y publicaremos los resultados cuando suceda. –

+0

@NikolaiNFetissov Lo has clavado. Encontrado la raíz del problema finalmente. –

Respuesta

4

Después de jugar con esto por un poco he encontrado que una sola SYN -> SYN-ACK -> secuencia RST elevará el caso SocketAsyncEventArgs.Completed y causar la propiedad SocketAsyncEventArgs.SocketError para convertirse en SocketError.ConnectionReset. Parece que este es el comportamiento esperado, pero definitivamente es un problema y debería documentarse mejor.

Cualquier puerto que escanee su servidor y realice una exploración de tipo SYN semiabierta generará un tráfico similar y causará el mismo problema. Para prevenir las vulnerabilidades de denegación de servicio en el software, uno debe manejar esta condición especial.

+0

¿Cómo crees que debería manejarse? ¿Tragar la excepción o cerrar la conexión? –

+0

@HarryMexican Debe capturar la excepción, liberar los recursos y comenzar a aceptar nuevamente. Si necesita bloquear escaneos SYN, necesita un cortafuegos que soporte la inspección de paquetes con estado y el filtrado automático del tráfico, o algunas reglas de cortafuegos muy agresivas. –

-1

Tal vez esto podría ayudar: Socket problem: TcpClient.GetStream with ReceiveTimeout throws Exception and connected state become false

Si los tiempos ficha de salida, también se puede enviar paquetes a mantener con vida cada pocos segundos (minutos).

También puede estar pendiente de la conexión utilizando Netstat -an | findstr/i "PORT #". Puede encontrar información al respecto en: TCP Connection States and Netstat Output

Espero que ayude a rastrear su problema.

Cuestiones relacionadas