Experto en comunicaciones ¿alguien sabe cual es el problema?

[closer]

Hola a todos, este es mi primer post  ya que me ha surgido una problema con una aplicación, y he pensado: "Seguro que en el Hacker.net hay alguien que sepa de este tema"; y eso he hecho, así que, os comento.

Tengo una problema de comunicaciones y me gustaría saber si alguien pudiera saber a que se debe.

Os pongo en situación:
Tengo dos máquinas, servidor y cliente y un switch. El cliente pide archivos por UDP al servidor (a través el switch),
y el servidor le responde por UDP multicast (también por el switch); el motivo del multicast es que en el futuro se
aumentaría el numero de clientes en la red.

Hasta aquí todo correcto, el sistema cliente - servidor funciona; ¿problema? Pues que cuando el servidor envía muchos
archivos (tanto que la red se establece al máximo de 1gb/s) al ratito (menos de 5 minutos) el cliente, por causa desconocida que
me gustaría saber, deja de recibir tal cantidad de archivos y empieza a recibirlos muy lentamente. Por tanto,
como esos archivos no le están llegando al cliente con suficiente rapidez, éste, los sigue pidiendo al servidor y el
servidor sigue reenviando los mismos archivos a la misma velocidad que siempre (solo que le llega una pequeñisima parte) por
lo que entra en un bucle casi infinito.

Las pruebas que he estado haciendo he descartado:
-No es problema de hilos.
-No es la aplicacion que se congela, no se ve afectada por la velocidad.
-No hay problema de cpu.
-No hay firewall, con red cerrada y sin internet.
-Siguen llegando paquetes, pero despacio.
-Si el servidor se para (deja de enviar paquetes), y espero algunos unos segundos vuelve a recibir como al principo (al maximo de la red).
-El administrador de tareas muestra como que sigue recibiendo a 1gb/s (incluso cuando los paquetes le llegan muy lento), es un tanto extraño porque si le llegan lentamente en la gráfica del administrador de tareas se debería de haber reflejado.

Parece ser como si se saturara los paquetes y no llegara al cliente (por lo que el switch no parece ser el culpable).


Por ahora estoy haciendo pruebas de estrés ya que en circusntancias normales funciona perfectamente, pero como
en el futuro habrá varios clientes, es un intento de simular lo que podría pasar en condiciones extremas.

¿Por qué ocurre esto? ¿Por qué el cliente por causa desconocida empieza a recibir menos? 

A mi parecer creo que windows o la propia tarjeta de red está frenando o evitando que llegue tal cantidad de
archivos.
¿Alguien tiene alguna idea?

Gracias de antemano. Saludos!

[warcry.]

yo diría que lo que se satura es el switch por el multicast.

Prueba a unir directamente el cliente con el servidor a ver si se te congela para descartar el switch

si sigue igual, no es problema del switch, si se arregla entonces si

[engel lex]

sinceramente me ha pasado incluso en unicast, mandando a una ip, llega un momento que el servidor no recibe más despues de algunos MB... he resuelto enviando un paquete de vuelta (aunque no sea escuchado) cada cierto tiempo... para ser sincero, me tuvo sin cuidado ese momento, pero me da curiosidad esto...

[AXCESS]

Interrogantes (Son de peso en la búsqueda de su solución):
"...me ha surgido una problema con una aplicación..."
-Cuál?
-Puede alterar la configuración TCP/IP: Tamaño máximo de paquetes (MTU), o el tamaño de la ventana de recepción (RWIN)?
"Los datagramas pueden pasar por varios tipos de redes con diferentes tamaños aceptables antes de llegar a su destino. Por tanto, para que un datagrama llegue sin fragmentación al destino, ha de ser menor o igual que el menor MTU de todos los de las redes por las que pase.
En el caso de TCP/UDP, el valor máximo está dado por el MSS (Maximum Segment Size), y toma su valor en función de tamaño máximo de datagrama, dado que el MTU = MSS + cabeceras IP + cabeceras TCP/UDP. En concreto, el máximo tamaño de segmento es igual al máximo tamaño de datagrama menos 40 (que es número mínimo de bytes que ocuparán las cabeceras IP y TCP/UDP en el datagrama).
Lamentablemente, cada vez más redes bloquean todo el tráfico ICMP (p.ej. para evitar ataques de denegación de Servicio - DoS (Denial of Service), lo que impide que funcione el descubrimiento del MTU del camino. A menudo podemos detectar estos bloqueos cuando la conexión funciona para un bajo tráfico de datos, pero se bloquea tan pronto como un host envía un bloque grande de datos de una vez. También, en una red IP el camino desde el origen al destino a menudo se modifica dinámicamente, como respuesta a sucesos variados (balanceo de carga, congestión, etc.); esto puede hacer que el MTU del camino cambie (a veces repetidamente) durante una transmisión, lo que puede introducir que los paquetes siguientes sean desechados antes de que el host encuentre un nuevo MTU fiable para el camino.
La mayoría de las redes de área local ethernet usan una MTU de 1500 bytes."   Fuente – Wikipedia.
-Cómo sabe que la comunicación es UDP y no TCP?
Sugerencias:
"...deja de recibir tal cantidad de archivos y empieza a recibirlos muy lentamente."
-Descartar el cable LAN (Probar otro). Son más frágiles de lo que se piensa y pudiera causar ese fallo.
-Según describe, parece ser un cuello de botella en la configuración de la tarjeta de Red en Windows (suele pasar al sobresaturar el ancho de banda).
Dele la configuración manual: Quitarle el automático (por defecto); ponerle el dúplex completo (full) a la velocidad que necesita.
Otro cambio: (Exclusivamente experimental!)
Número de búferes de recepción: valor: 512
Número de búferes de transmisión: valor: 256
Esto viene por defecto:
Cambiar a 512 la transmisión.
Nota: Anterior configuración de riesgo: Puede dar problemas en algunos servidores y configuraciones de red (en otras funciona de maravillas) Recomiendo experimentar, y si va mal, dejar por defecto.
Chequear los valores máximos por segundos del IRQ, tanto del servidor como del cliente. (No debe ser esto)
Establecer tráfico y stress.
Chequear en el Bios del motherboard, la configuración de red (LAN on board). Configurar manual, si avala.
Probar servidor - cliente directo (buena la recomendación de descartar el switch).
Implementar un paso a la vez; probar; deshacer si no hay resultados positivos.
Si persiste el problema:
Deshabilitar la tarjeta de red onboard (por el Bios) y probar con una PCI.
Si nada de lo anterior ha sido de ayuda...
Ignorar como si se tratase del borracho del pueblo.
[El camino al infierno está lleno de buenas intenciones]