Crear errores de red para probar un sistema distribuido

Question

Estoy desarrollando una biblioteca Java para comunicación a través de HTTP y quiero probar su fiabilidad y rendimiento en caso de problemas de red como pérdida de paquetes, alta latencia, bajo ancho de banda y congestión. Estoy usando Apache's httpclient library para hacer conexiones desde el lado del cliente, y el propio com.sun.net.httpserver.HttpServer de Java para iniciar servidores HTTP.

¿Hay bibliotecas disponibles que hacen ese tipo de cosas, o debo hacer las mías? Creo que podría intentar conectar mi propio org.apache.http.conn.scheme.SchemeSocketFactory en el lado del cliente, y simular varios de los problemas mencionados anteriormente con eso, pero preferiría usar algo que ya funciona :-)

Esto es similar a la pregunta Creating TCP network errors for unit testing, pero estoy buscando soluciones que involucren Java en Linux. He examinado el clic, que se sugirió para esa pregunta, pero no estoy seguro de que pueda proporcionar lo que estoy buscando.

Answer 1

Dado que las API de Java no tienen acceso a las API de red de bajo nivel, emularlas sería un desafío.

Alternativamente La biblioteca de componentes Apache HTTP Core puede tener algo que lo ayude a simular la latencia y la pérdida de datos y posiblemente problemas de ancho de banda. La biblioteca tiene la función de inyectar sus propios búferes de entrada y salida de sesión. Puede encontrar la documentación en Advanced Features of HTTP Core

Mediante la inyección de su propio buffer

• latencia puede ser un pequeño retraso inyectado en la lectura y escritura
• pérdida de datos es algunos bytes tirados a la basura. No es pérdida de paquetes en el verdadero sentido, ya que no hay reenvío de duplicados.
• El ancho de banda se puede limitar ajustando las operaciones de lectura/escritura y descarga.
• El tráfico es difícil de simular, excepto por una ralentización excesiva de lectura y escritura en el búfer.

También puede consultar TCPProxy disponible en el proyecto Grinder. No lo he visto en detalle. La documentación muestra EchoFilter como ejemplo, pero creo que debería ser posible extender los filtros para retrasar el envío y la recepción de bytes dentro de la transmisión. Pero tiene sentido usar un proxy para simular problemas de red. De esta forma, su cliente y su servidor permanecen felizmente ignorantes de las pruebas que se están llevando a cabo.

En ambos casos, la simulación de problemas de red parece ser el mejor esfuerzo posible en Java. O bien puede configurar un firewall local y configurarlo para interceptar y jugar con los paquetes que recibe.

Espero que haya sido útil.

Answer 2

En lugar de tratar de implementar errores de red (en su caso podría significar modificar la biblioteca httpclient o simular errores y retrasos en el servidor), debe considerar utilizar un emulador WAN como WANEM. Sería una solución más simple y más factible, en mi opinión.

Answer 3

Si no está realizando pruebas de integración del sistema, si ejecuta la pila completa con servidores externos, etc., entonces lo que está buscando es utilizar herramientas de burla. Le permiten registrar el comportamiento de la biblioteca contra la que está trabajando. Esto le ahorra ejecutar el código de la biblioteca, que no debería necesitar verificación.

Usando algo como mockito, o si es necesario PowerMock, puede decirle a la biblioteca que genere excepciones cuando se invoca un método que invoca.

Ejemplo:

import static org.mockito.Mockito.mock 
import static org.mockito.Mockito.when 
... 
@Test(expected=HttpException.class) 
public void invockationThrowsHttpException() { 
    ... 
    HttpClient httpClient = mock(HttpClient.class) 
    when(httpClient).executeMethod(args...).thenThrow(HttpException...) 

    underTest.invokeCodeUnderTest(args...) 
    ... 
} 

El ejemplo anterior asume junit4. Hay un buen tutorial en el sitio web de Mockito. PowerMock se usa si necesita simular cosas que Mockito no simula (por ejemplo, métodos estáticos o finales).

Como nota aparte, me di cuenta de que el cliente HTTP de Apache está en fin de vida y que, en su lugar, recomiendan cambiar a los componentes HTTP de Apache. Si su proyecto todavía está en etapas tempranas, puede valer la pena cambiarlo ahora.