C# SocketasynceVentArgs deja de disparar evento completado

Question

He notado un problema en el que el evento. parece dejar de disparar. La misma SAEA puede disparar correctamente y ser reemplazada en la piscina varias veces, pero eventualmente todas las instancias dejarán de disparar, y debido a que el código para reemplazarlos en la piscina está en el controlador de eventos, la piscina vacía.

los Siguiente circunstancias También son aparentemente ciertos:

1) Parece que solo ocurre cuando un socket del lado del servidor envía datos a uno de los clientes conectados. Cuando la misma clase se conecta como cliente, no parece funcionar mal.

2) Parece ocurrir bajo una carga alta. El recuento de hilos parece aumentar hasta que finalmente ocurre el error.

3) Una plataforma de prueba bajo estrés similar parece que nunca funcionan mal. (Son solo 20 mensajes por segundo, y la plataforma de prueba se ha demostrado a 20k)

No voy a poder pegar el código bastante complicado, pero aquí hay un Descripción de mi código:

1) La principal inspiración es esta: http://vadmyst.blogspot.ch/2008/05/sample-code-for-tcp-server-using.html. Muestra cómo conectar un puerto de finalización utilizando un evento, cómo obtener mensajes de diferentes tamaños a través de la conexión TCP, etc.

2) Tengo un búfer de byte en el que todos los saeas tienen una pieza, que no se superpone.

3) Tengo un conjunto de objetos de Saeas, basado en una colección de bloqueo. Esto lanza si la piscina está vacía durante demasiado tiempo.

4) Como servidor, mantengo una colección de enchufes devueltos de la función Accessync, indexada por el punto final del cliente. Un solo proceso puede usar una instancia como servidor, así como múltiples instancias como clientes (formando una web). Comparten el búfer de datos y el grupo de Saeas.

Me doy cuenta de que es difícil explicar esto; Lo he estado depurando durante todo un día y una noche. Solo espero que alguien haya oído hablar de esto o tenga preguntas o sugerencias útiles.

Por el momento, sospecho que algún tipo de agotamiento de hilos, lo que lleva a que los Saeas no puedan llamar la finalización. Alternativamente, algún tipo de problema del búfer en el búfer saliente.

Answer 1

Entonces, otro día de depuración y finalmente tengo una explicación.

1) Los Saeas no estaban disparando el evento completo porque no pudieron enviar más. Wireshark revela que esto se debe al vaciado de la ventana TCP. (Tcp zerowindow)

2) La ventana TCP estaba vaciando porque la capa de red estaba pasando un evento por la pila que tardó demasiado en completarse, es decir, no hay productor/consumidor entre la capa de red y la interfaz de usuario. Por lo tanto, el OP de red tendría que esperar el dibujo de la pantalla antes de enviar el ACK.

3) El evento que tardó demasiado fue un sorteo de pantalla en un controlador de eventos en la GUI. La plataforma de prueba era una ventana de consola (una que resumía los mensajes entrantes), por eso no causó un problema a una carga mucho más alta. Es normal no volver a dibujar la pantalla en cada mensaje, pero esto estaba sucediendo porque el proyecto aún no ha terminado. La tasa de redibujado se habría arreglado más tarde.

4) La solución a corto plazo es simplemente asegurarse de que no haya GUI manteniendo el espectáculo. Una solución más robusta podría ser crear un productor/consumidor en la capa de red.