Vida de conexión TCP

Question

¿Cuánto tiempo puedo esperar que una conexión TCP cliente / servidor dure en el futuro?

Quiero que permanezca conectado permanentemente, pero las cosas suceden, por lo que el cliente tendrá que volver a conectarse. ¿En qué punto digo que hay un problema en el código en lugar de un problema con algún equipo externo?

Answer 1

Estoy de acuerdo con Zan Lynx. No hay garantía, pero puede mantener una conexión activa casi indefinidamente enviando datos a través de ella, suponiendo que no haya problemas de conectividad o ancho de banda.

En general, opté por el enfoque de mantener la vida en el nivel de la aplicación, aunque esto generalmente se debe a que está en la especificación del cliente, así que tuve que hacerlo. Pero solo envíe algunos datos cortos cada uno o dos minutos, a los que espera algún tipo de reconocimiento.

Depende de usted si cuenta un error de confirmación ya que la conexión ha fallado. En general, esto es lo que he hecho en el pasado, aunque hubo un caso en el que esperé tres respuestas seguidas para interrumpir la conexión, ya que la aplicación en el otro extremo de la conexión no tenía nada que ver con responder, ¿estás allí? " peticiones.

Si la conexión falla, lo que en algún momento probablemente lo hará, incluso con las máquinas en la misma red, simplemente intente restablecerla. Si eso falla un número determinado de veces, entonces tienes un problema. Si su conexión falla de manera persistente después de haber estado conectada por un tiempo, entonces tiene un problema. Lo más probable es que en ambos casos sea probablemente un problema de red, en lugar de su código, o tal vez un problema con la pila TCP / IP en su máquina (se sabe: encontré problemas con esto en una versión antigua de QNX; solo caerse al azar). Habiendo dicho que es posible que tenga un problema de software, y la única manera de saberlo con seguridad es a menudo adjuntar un depurador, o para obtener algún tipo de inicio de sesión allí. P.ej. si siempre puedes conectarte con éxito, pero después de un tiempo dejas de recibir ACK, incluso después de volver a conectarte, es posible que tu servidor esté bloqueado o se quede atascado en un bucle o algo así.

Lo que es realmente útil es configurar una serie de pruebas de larga duración en una variedad de condiciones de carga, desde el simple hecho de enviar la alerta, ¿estás ahí? / Ack solicitudes y respuestas, para golpear absolutamente el servidor. Por lo general, esto le dará más confianza acerca de los componentes de su software y puede ser realmente útil para solucionar algunos problemas realmente extraños que no necesariamente causarán un problema con su conexión, aunque pueden dar lugar a problemas con las transacciones que tienen lugar. Por ejemplo, una vez estaba escribiendo un servidor de aplicaciones de telecomunicaciones que proporcionaba servicios como la traducción de números, y lo dejábamos funcionando durante varios días. La cuestión era que cuando llegara el sábado, durante todo el día, rechazaría cada solicitud de llamada que llegara, lo que equivalía a millones de llamadas, y no teníamos idea de por qué. Resultó ser debido a un solo error tipográfico en un código de conversión de fecha que solo causó un problema los sábados.

Espero que ayude.

Answer 2

Creo que la idea más importante aquí es la teoría frente a la práctica.

La teoría original era que las conexiones no tenían tiempos de vida. Si tenía una conexión, permanecía abierta para siempre, incluso si no había tráfico, hasta que un evento provocó el cierre.

La nueva teoría es que la mayoría de las versiones del sistema operativo han activado el temporizador de mantenimiento. Esto significa que las conexiones durarán para siempre, siempre que el sistema en el otro extremo responda a un intercambio ocasional de nivel TCP.

En realidad, muchas conexiones se terminarán después del tiempo, con una variedad de criterios y situaciones.

Dos ejemplos realmente buenos son: el cliente remoto está usando DHCP, la concesión vence y la dirección IP cambia.

Otro ejemplo son los firewalls, que parecen ser cada vez más inteligentes y pueden identificar el tráfico de mantenimiento frente a los datos reales, y cerrar las conexiones según cualquier criterio de alto nivel, especialmente el tiempo de inactividad.

La forma en que desea implementar la lógica de reconexión depende mucho de su arquitectura, el entorno de trabajo y sus objetivos de rendimiento.

Answer 3

Realmente no debería importar, debes diseñar tu código para que se vuelva a conectar automáticamente si ese es el comportamiento deseado.

Answer 4

Realmente no hay manera de decirlo. No hay nada inherente a TCP que haga que la conexión se caiga luego de un cierto tiempo. Una persona con una conexión confiable podría tener años de actividad, mientras que otra persona con una conexión diferente podría tener que volver a conectarse cada 5 minutos. No hay manera de decir o adivinar.

Answer 5

Necesitará que algunos datos se transfieran periódicamente a través de la conexión para mantenerlos activos. Muchos sistemas operativos o cortafuegos eliminarán una conexión inactiva.

Answer 6

Elija un valor. Una gota cada hora probablemente esté bien. Diez caídas inesperadas de conexión en 5 minutos probablemente indican un problema.

Las conexiones TCP generalmente durarán aproximadamente dos horas sin tráfico. Cualquiera de los dos extremos puede enviar paquetes keep-alive, que son, creo, solo un ACK en el último paquete recibido. Por lo general, esto se puede establecer por socket o por defecto en cada conexión TCP.

Un nivel de aplicación keep-alive también es posible. Para un protocolo de estilo telnet como FTP, SMTP, POP o IMAP algo como enviar devolución, nueva línea y recuperar un indicador de comando.