Este es un viejo problema que abandoné hace un tiempo porque no podía solucionarlo y solo afectaba a un servidor (así que simplemente coloqué mi servicio en otro lugar). This usuario tiene un problema con síntomas idénticos a la mía:Rotura de búfer de Tcp en .NET runtime
- C servidor # .NET Tcp sincrónica
- un objeto TcpClient se asigna mediante el bloqueo en una TcpListener con el método AcceptTcpClient
- una vez que hay un objeto TcpClient , lo paso a un hilo que invoca el método GetStream del cliente para crear un NetworkStream
- este NetworkStream se enrolla sobre, en cada iteración haciendo un networkStream.Read (someBuffer, 0, 4096)
- en este momento el cliente y el servidor se encuentran en la misma red, sin la congestión hablar de
- mi servidor tiene un montón de memoria de sobra
- si me carga el software de servidor en otra máquina, el problema desaparece
- lo bueno: tráfico desde una máquina Linux a través de la red obtiene bien ya tiempo
los tcpClient.AcceptTcpClient() bloques del procedimiento para alrededor de un minuto a la vez, lo que resulta en el servidor de tener que leer un gran bloque de bytes poco tiempo después, en lugar de lo que debería hacer. Debería hacer networkStream.Read() pequeños bloques de bytes tan frecuentemente como se envían (y el cliente los envía cada 5 s, no una vez por minuto).
Los comentarios anteriores al otro usuario sugieren problemas de red o conectividad por debajo de lo normal, que a primera vista parece razonable. Pero este no es realmente el caso.
Fui un paso más allá e instalé analizadores de paquetes tanto en el cliente como en el servidor. Resultados:
- la instantánea El cliente envía una que aparece en el analizador del servidor
- latencia de red o conectividad no son el problema
- el paquete/trama están llegando al servidor en el momento correcto
- en algún lugar entre la tarjeta de interfaz de red que mi analizador está monitoreando y mi aplicación algo está causando este retraso
- .NET runtime es lo único entre mi aplicación y netwo rk operación de interfaz
- algún tipo de error de socket en .NET es la causa de esta gran latencia
Medio Ambiente:
- en mi caso particular estoy usando un Intel PRO/1000 Tarjeta de red MT, y .NET
- Standard Edition Server 2003 R2, SP2
- .NET Frameworks instalado: 2.0 SP2, 3.0 SP2, 3.5 SP1, 4 Client Profile, 4 Extended
Si alguien tiene algún consejo, me gustaría saber de qué se trata.
¿Cómo se manejan las solicitudes simultáneas? es decir, ¿engendras un hilo por cliente o algo más? , y en el momento en que esto ocurre, puede ser útil depurar cuántos clientes concurrentes están conectados en ese momento (para asegurarse de que no está llegando a un límite donde se encuentran varios clientes muertos/rotos, podría llevar a alguien haciendo el puerto). escaneo para disparar de una tonelada de hilos en su aplicación) – nos
@nos Hay un único punto de entrada y a los clientes únicos se les asigna su propio objeto TcpClient exclusivo, que obtiene su propio hilo para procesar los contenidos entrantes de un NetworkStream.Read(). Así que sí, 1 hilo por cliente, con pocos clientes que usan el servicio para el futuro previsible. Y en prueba solo hay 1 cliente conectado. –
Lo único que se me ocurre además de un problema entre la pila del sistema operativo y su aplicación es algo en los encabezados de paquetes enviados a través del cable. Para ser más específico, tal vez el bit PSH no está establecido en los encabezados TCP para el caso en que falla. Podría intentar ejecutar un sniff de paquete en un servidor que funcione y otro que sí lo haga. Luego compara los dos y ve si hay alguna diferencia. –