protocolo - tcp medicina
Vida de conexión TCP (6)
Elige un valor. Una gota cada hora probablemente esté bien. Diez caídas de conexión inesperadas en 5 minutos probablemente indiquen un problema.
Las conexiones TCP generalmente durarán aproximadamente dos horas sin tráfico. Cualquiera de los extremos puede enviar paquetes keep-alive, que son, creo, solo un ACK en el último paquete recibido. Esto generalmente 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 de telnet como FTP, SMTP, POP o IMAP, algo como enviar de regreso, nueva línea y obtener un símbolo del sistema.
¿Cuánto tiempo puedo esperar que una conexión TCP cliente / servidor dure en la naturaleza?
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 que haya algún problema con algún equipo externo?
En realidad no debería importar, debe diseñar su código para reconectarse automáticamente si ese es el comportamiento deseado.
Estoy de acuerdo con Zan Lynx. No hay garantía, pero puede mantener viva una conexión casi indefinidamente enviando datos sobre ella, suponiendo que no hay problemas de conectividad o ancho de banda.
En general, he optado por el enfoque keep-alive a nivel de aplicación, aunque esto generalmente se debe a que ha estado en la especificación del cliente, así que tuve que hacerlo. Pero solo envíe algunos datos breves cada minuto o dos, a los que espera algún tipo de reconocimiento.
Si usted cuenta una falla al reconocer que la conexión falló, depende de usted. En general, esto es lo que hice en el pasado, aunque hubo un caso en el que tuve que esperar tres respuestas fallidas seguidas para desconectar la conexión porque la aplicación al otro extremo de la conexión estaba extremadamente inestable al responder "¿estás ahí? ? " peticiones.
Si la conexión falla, lo que en algún momento probablemente ocurrirá, incluso con máquinas en la misma red, entonces simplemente intente restablecerla. Si eso falla una cantidad determinada de veces, entonces tienes un problema. Si su conexión falla persistentemente después de haber sido conectada por un tiempo, entonces nuevamente, usted 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 ha sabido: encontré problemas con esto en una versión anterior de QNX; simplemente caer al azar). Una vez dicho esto, es posible que tenga un problema de software, y la única manera de saberlo con seguridad es adjuntar un depurador o iniciar sesión allí. Por ejemplo, si siempre puedes conectarte con éxito, pero después de un tiempo dejas de recibir ACK, incluso después de volver a conectarte, entonces tal vez 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 simplemente enviar el mantenimiento vivo ¿está usted allí? / Ack solicitudes y respuestas, para golpear absolutamente el servidor. En general, esto le dará más confianza sobre los componentes de su software, y puede ser realmente útil para eliminar algunos problemas realmente extraños que no necesariamente causarán un problema con su conexión, aunque pueden ocasionar problemas con las transacciones que se llevan a cabo. Por ejemplo, una vez escribí un servidor de aplicaciones de telecomunicaciones que proporcionaba servicios, como la traducción de números, y simplemente lo dejábamos en funcionamiento durante días. El caso es que cuando llegara el sábado, durante todo el día, rechazaría todas las solicitudes de llamadas que llegaran, lo que representaba millones de llamadas, y no teníamos idea de por qué. Resultó ser debido a un único error tipográfico en algún código de conversión de fecha que solo causaba un problema los sábados.
Espero que ayude.
Necesitará que algunos datos revisen la conexión periódicamente para mantenerla activa: muchos SO o firewalls dejarán de existir una conexión inactiva.
Realmente no hay forma de saberlo. No hay nada inherente a TCP que haga que la conexión simplemente caiga después de una cierta cantidad de tiempo. Alguien con una conexión confiable podría tener años de disponibilidad, mientras que alguien con una conexión diferente podría tener que reconectarse cada 5 minutos. No hay forma de decir o incluso adivinar.
Creo que la idea más importante aquí es teoría vs. 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 hacía que se cerrara.
La nueva teoría es que la mayoría de las versiones del sistema operativo han activado el temporizador de mantener activo. 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 terminarán después de un tiempo, con una variedad de criterios y situaciones.
Dos ejemplos realmente buenos son: El cliente remoto está utilizando DHCP, la concesión vence y la dirección IP cambia.
Otro ejemplo son los cortafuegos, que parecen ser cada vez más inteligentes, y pueden identificar el tráfico "keep-alive" vs. datos reales, y las conexiones cercanas basadas en cualquier criterio de alto nivel, especialmente el tiempo de inactividad.
La forma en que desee implementar la lógica de reconexión depende mucho de su arquitectura, el entorno de trabajo y sus objetivos de rendimiento.