¿Tiempos de espera infinitos o "fallan rápido" en el protocolo de red personalizado?

Question

Considere el protocolo de red personalizado. Este protocolo personalizado podría usarse para controlar periféricos robóticos a través de LAN desde una estación de trabajo central basada en .NET. (Si es importante, el robot está ocupado moviendo fabs en el entorno de producción de chips).

• solo hay dos partes en la conversación: estación .NET y pizarra robótica periférica
• el lado robótico solo puede recibir solicitudes y enviar respuestas
• el lado .NET solo puede iniciar solicitudes y recibir respuestas
• siempre debe haber exactamente una respuesta por solicitud
• las solicitudes consiguientes pueden seguir inmediatamente una tras otra sin esperar respuesta, pero nunca exceder el límite fijo de solicitudes atendidas simultáneamente (por ejemplo, 5)

Tuve una discusión exhaustiva con mi amigo (que posee el diseño, he discutido la cosa como un espectador) sobre todos los detalles e ideas agradables. Al final de la discusión tuvimos un fuerte desacuerdo sobre los tiempos de espera perdidos. El argumento de mi amigo es que el software en ambos lados debe esperar indefinidamente. Mi argumento fue que los tiempos de espera siempre son necesarios para cualquier protocolo de red. Simplemente nunca podríamos estar de acuerdo.

Uno de mis razonamientos es que, en caso de cualquier falla, deberías " fallar rápido " cueste lo que cueste, porque si el fallo ya ocurrió de todos modos, el costo de la recuperación continúa creciendo proporcionalmente al tiempo empleado en recibir información sobre el fracaso. Diga que después de 1 minuto en LAN, definitivamente debería dejar de esperar y solo activar una alarma.

Pero su argumento fue que la recuperación debe incluir exactamente la reparación de lo que falló (en este caso, la recuperación de la conexión de red) e incluso si se tarda varias horas en descubrir que la red se perdió y se reparó, el software debería continuar de manera transparente en ejecución, inmediatamente después de volver a conectar los cables LAN.

Nunca pensaría seriamente en los protocolos atemporales, hasta esta discusión.

¿Qué lado del argumento es correcto? El " falla rápido " o "nunca fallar" ?

Editar: el ejemplo de falla es la pérdida de comunicación, normalmente detectada por la capa TCP. Esta parte también fue discutida. En caso de que el error de la capa TCP regrese, la capa de protocolo personalizado superior reintentará los envíos y no hay ningún argumento al respecto. La pregunta es: ¿durante cuánto tiempo permitir que el nivel inferior siga intentando?

Editar para respuesta aceptada: La respuesta es más compleja que 2 opciones: " El enfoque más común nunca es abandonar la conexión hasta que el intento de envío falla, con una confirmación sólida de que la conexión se perdió por mucho tiempo. Para calcular que la conexión se ha perdido durante mucho tiempo, use los latidos del corazón, pero mantenga la antigüedad de la pérdida solo para esta confirmación, no para la alarma inmediata " ;.

Ejemplo: al tener una sesión de telnet, puedes mantener tu terminal arriba para siempre y nunca sabes si al presionar Enter se detectaron fallas en las rutinas de nivel inferior.

Answer 1

Prefiero tu " falla rápida " método, pero como creo que has descubierto, esto es altamente preferencial.

Los equipos de Cisco con los que trabajo funcionan de manera muy similar: usted envía una solicitud, ellos responden. (A través de telnet). El problema es cuando falla la red: pierdo la conexión TCP. Sin embargo, ninguno de los dos lados cerrará esa conexión hasta que se intente un envío de datos, y dado que el lado de Cisco rara vez hace eso, nunca se cierra. Peor aún, solo puede tener 1 conexión a la vez, por lo que si hay un fallo en la red, está bloqueado. (Se pueden restablecer, pero es solo una molestia).

Ahora, para probar una conexión de red, necesitas algún tipo de ping, solo un " ¿sigues ahí? " - Muchos protocolos hacen esto, como AIM e IRC. Pero esos pings cuestan el ancho de banda, dependiendo de la frecuencia con la que los envíes.

Entonces, ¿vale la pena el costo de detección de errores en ancho de banda? ¿Qué tan grande realmente necesita ser un ping? Yo diría que deberías poder llegar a < 50 octetos / ping, y puedes hacer ping como una vez cada 10s, 30s, 1m, algo así, yo diría que vale la pena. Cuanto antes sepa que tiene un problema, mejor. Si el propio software puede usar estos pings para saber que perdió la conexión y restablecer el contacto automáticamente, diría que es genial, en la línea de "Computadora, cúrate", y crea menos problemas para el operador.

Si está usando TCP / IP, puede hacerlo automáticamente por usted, vea TCP Keepalives. Alternativamente, puede hacerlo dentro del protocolo de su aplicación, como AIM & amp; IRC hacer.

Answer 2

En el escenario donde ...

• El controlador ha enviado una solicitud
• El robot no ha recibido la solicitud
• La red falla

... luego se envió la solicitud, pero se perdió y nunca llegará.

Por lo tanto, cuando se restaura la red, el controlador debe reenviar la solicitud: el controlador no puede simplemente esperar para siempre la respuesta.