¿El enchufe se desconecta en un extremo, firewall?

Question

Tengo una aplicación C # que ha estado funcionando bien durante varios años. Se conecta a través de un socket TCP / IP a una máquina que me envía ejecuciones comerciales de acciones.

Recientemente, intenté implementarlo en algunas máquinas en un nuevo centro de datos que está detrás de un firewall de hardware, y comencé a ver algunas desconexiones extrañas.

Cuando ocurre una desconexión, en mi aplicación (del lado del cliente), no veo nada inusual, excepto que dejo de recibir datos a través del socket. Wireshark confirma que no hay datos llegando al socket y que el hilo de recepción de mi aplicación se bloquea en la llamada Recibir () cuando lo detengo en el depurador. El socket se muestra ESTABLECIDO en netstat.

Pero desde el lado del servidor, parece que mi cliente se está desconectando. Al mirar sus registros, parece que el socket de su extremo generalmente termina con (nRecvd = -1, errno = 104) o (nRecvd = 0, errno = 11). (104 es restablecimiento de la conexión por par).

La desconexión solo parece ocurrir después de un período de actividad. Resolví esto por ahora implementando un latido entre mi cliente y su servidor que solo envía un mensaje corto cada 20 segundos y recibe una respuesta. Esto ha provocado que las desconexiones caigan a 0 en los últimos días.

Al principio, pensé que el firewall del hardware era el problema. Estaba causando que el socket se agotara después de la actividad. Pero la persona a cargo del firewall afirma que el tiempo de espera para las conexiones en este puerto (8887) es de 2160 minutos.

Estoy ejecutando Windows Server 2003 y .NET 3.5. El servidor de operaciones es una máquina Linux (sles9, aunque creo que no estoy seguro).

¿Alguna idea sobre lo que podría estar pasando? ¿Qué podría hacer para depurar esto más dado que no tengo acceso a los registros del firewall y no puedo cambiar el código en el servidor comercial?

Gracias Mike

Answer 1

Lo que usted describe es común, y es común implementar un latido para mantener vivos los sockets TCP a través de firewalls / puertas de enlace como lo hizo usted.

Ese hardware podría tener tiempos de espera de 2160 minutos (en mi experiencia, 20-30 minutos es más común), pero las conexiones generalmente se caen mucho más agresivamente si hay algún tipo de carga. Dichos cortafuegos tienen recursos limitados, y cuando necesitan más seguimiento de conexión, tienden a eliminar la conexión más antigua rastreada sin ninguna actividad, independientemente del tiempo de espera establecido.

Si desea depurar esto más, huela en el lado del servidor del firewall y vea qué sucede, si corresponde, cuando el servidor se desconecta

Answer 2

Configuraría wireharp en ambos lados del firewall para ver qué sucede en TCP (y en el nivel inferior). Y cuando el administrador dice el " tiempo de espera para conecta " es algo. ¿Es ese el tiempo de espera para una conexión inactiva y establecida? Cualquier otra cosa no tiene ningún sentido, supongo.

Además, ¿estás usando la opción KeepAlive para TCP? ¿Y es reenviado por el firewall o no?

Como dije, probablemente quiera ejecutar wireshark en ambos lados del firewall ...