De monstruosidad de explicación nada. De nuevo, muchas gracias por tu extensa respuesta. Te lo agradezco. Theliel
Todo lo que explicas lo entiendo perfectamente recordando mi breve formación en redes, ya que yo soy más de sistemas.
Entiendo que la gestión de tráfico en switches y routers debe ser muy compleja y por ello existen routers y switches empresariales muy complejos. Recuerdo mis tiempos de Outsourcing de gestión de sistemas en que veía a los chicos de redes que gestionaban los Cisco gigantescos y me parecía un mundo inabordable.
Tengo en mente la simplificación del buffer overflow y del control de flujo. Es decir, antes de que se llene el buffer, el control de flujo actúa y para la transmisión. Que los clientes reintenten…
Evidentemente esto es una simplificación ya que los algoritmos para implementar eso, cuando hay multitud de tráfico desde muchos pares simultáneamente, tiene que ser compleja para asegurar el rendimiento global que ve cada nodo en la red, que casi ve que tiene todo el ancho de banda para él solito.
Por cierto, mis switches tp-link tienen un setting para cada puerto de “Flow Control” que está “Off” por defecto. Nunca los he puesto en “On” porque creo recordar haber leído en algún sitio que no hacía prácticamente nada y cuando los problemas aparecen apenas sirve para nada. Podría jugar con eso y tratar de saturar el router, pero como el problema es tan esporádico en este momento (hace meses que no ocurre) quizá sería más productivo que me dedique a “mis otros hobbies”.
EDIT: Ahora recuerdo algo sobre el "Flow Control" del tp-link, que decían algo así como que no merece la pena que el control fuerce a disminuir la velocidad (si es que se entiende con su par) por evitar que se descarten unos pocos paquetes. Es decir, venían a decir que el rendimiento puede bajar sustancialmente, por entrar en accion el "Flow Control", sin que sea necesario.
