networking - datagrama - udp protocolo
¿Cuáles son las posibilidades de perder un paquete UDP? (2)
Bien, entonces estoy programando para mi curso de redes y tengo que implementar un proyecto en Java usando UDP. Estamos implementando un servidor y un cliente HTTP junto con una función ''gremlin'' que corrompe los paquetes con una probabilidad específica. El servidor HTTP tiene que dividir un archivo grande en múltiples segmentos en la capa de aplicación para ser enviado al cliente a través de UDP. El cliente debe volver a ensamblar los segmentos recibidos en la capa de aplicación. Sin embargo, me pregunto si, por definición, el UDP no es confiable, ¿por qué tengo que simular aquí la falta de fiabilidad?
Mi primer pensamiento es que tal vez sea simplemente porque mi instructor está pensando en nuestro caso, tanto el cliente como el servidor se ejecutarán en la misma máquina y que el archivo se transferirá de un proceso a otro 100% de manera confiable incluso a través de UDP ya que Es entre dos procesos en la misma computadora.
Esto me llevó a cuestionar si UDP, perder un paquete, corromper un paquete o entregarlo fuera de servicio si el servidor y el cliente eran dos procesos en la misma máquina y no tenía que salir por la red real.
También me pregunto cuáles serían las posibilidades de perder realmente un paquete, corromperlo o entregarlo fuera de servicio en la realidad entre dos hosts geográficamente distantes.
Mucho aprecio a cualquiera que pueda arrojar algo de luz sobre cualquiera de estas preguntas para mí.
Si UDP no es confiable por definición, ¿por qué tengo que simular la falta de fiabilidad aquí?
Es muy útil tener un mecanismo controlado para simular los peores escenarios y cómo pueden responder tanto su cliente como su servidor. El instructor probablemente querrá que demuestres cuán robusto puede ser el sistema.
También está hablando de la validez de la carga útil aquí y no solo de la pérdida de paquetes.
Esto me llevó a cuestionar si UDP, perder un paquete, corromper un paquete o entregarlo fuera de servicio si el servidor y el cliente eran dos procesos en la misma máquina y no tenía que salir por la red real.
Obviamente, es menos probable sobre el adaptador de bucle invertido, pero esto no es imposible.
He encontrado algunos mensajes en el foro sobre el tema here y here .
También me pregunto cuáles serían las posibilidades de perder realmente un paquete, corromperlo o entregarlo fuera de servicio en la realidad entre dos hosts geográficamente distantes.
Esta pregunta probablemente debería reducirse un poco. Hay varios factores tanto en el nivel de aplicación (tamaño y frecuencia del paquete) como en las limitaciones / tráfico de enrutadores y conmutadores a lo largo de la ruta.
No pude encontrar ningún número importante en esto, pero parece ser bastante bajo ... como por debajo del 5%.
Puede estar interesado en el Informe de tráfico de Internet y posiblemente en páginas como this .
La pérdida de paquetes ocurre por múltiples razones. Principalmente es causado por errores en enlaces individuales y congestión de red.
La pérdida de paquetes debido a errores en el enlace es muy baja, cuando los enlaces funcionan correctamente. Menos del 0.01% no es inusual.
La pérdida de paquetes debido a la congestión obviamente depende de cuán ocupado esté el enlace. Si hay capacidad de reserva a lo largo de toda la ruta, este número será del 0%. Pero a medida que la red se llena, este número aumentará. Cuando el control de flujo se realiza correctamente, este número no será muy alto. Un par de paquetes perdidos suele ser suficiente para que alguien reduzca su velocidad de transmisión lo suficiente para evitar que los paquetes se pierdan debido a la congestión.
Si la pérdida de paquetes llega al 1%, algo está mal. Ese algo podría ser un error en la forma en que su algoritmo de control de congestión responde a la pérdida de paquetes. Si continúa enviando paquetes a la misma velocidad, cuando la red está congestionada y perdiendo paquetes, la pérdida de paquetes se puede empujar mucho más alto, la pérdida de paquetes del 99% es posible si el software se está portando mal. Pero esto depende de los tipos de enlaces involucrados. Gigabit Ethernet utiliza la contrapresión para controlar el flujo, por lo que si la ruta desde el origen hasta el destino es un solo segmento de Gigabit Ethernet, la aplicación de envío simplemente puede ralentizarse y nunca ver la pérdida real de paquetes.
Para probar el comportamiento del software en caso de pérdida de paquetes, sugeriría dos simulaciones diferentes.
- En cada paquete, colóquelo con una probabilidad del 10% y transmítalo con una probabilidad del 90%.
- Transmita hasta 100 paquetes por segundo o hasta 100 KB por segundo, y descarte el resto si la aplicación envía más.