> following problem occurs: > > host A from the outside connects to a service on the masqueraded server; > host A disconnects (power off, programm shutdown, network failure) ; > the masqueraded server keeps the connection - netstat says the connection is > ESTABLISHED (as opposed to being FIN_WAIT2). > > is it possible that the firewall is blocking some sort of tcp or icmp > communication that prevents such connections from being quickly identified > as "not functional"? > > eventually these connections do get closed, but this takes time. are there > some parameters to tune? > > i do not know the internals of the tcp/ip protocol well enough... maybe it > is something really simple. > > hints are greatly appreciated.
This is normal. When the remote system dies, there's no way for the near end to immediately tell if it crashed, got it's network cable cut, had the maid trip over the power cord, or just isn't sending any information. Eventually, your local server will send a packet to the far end (maybe sooner, maybe later...depends on the protocol you're running, if you're in the middle of doing anything interesting, and what your TCP connection keep-alive timers are set to). If no response is heard from the far end, eventually the remote system is marked as unreachable, and the connection is destroyed. Note that even in the middle of an active conversation, there's no method (short of a timeout, or "out of band" communication) to figure out if the remote system suddenly went offline or if something else is wrong. Maybe it just got busy and isn't talking to the 'net for a while (ie someone stuck a CD-ROM into your NT based server :-), or maybe an intermediate route on the internet went down, and packets will be re-routed in a couple seconds automatically. TCP includes advanced mechanisms for dealing with dropped packets, random delays, and just about any odd thing that can happen to packets between point A and point B. While you can play with the settings for the various timeouts and protocol settings to try and tweak performance, you probably need a much better understanding of TCP, and a REALLY good reason to try and do so. If you don't know EXACTLY what you're doing, you'll probably just make things much worse... Charles Steinkuehler http://lrp.steinkuehler.net http://c0wz.steinkuehler.net (lrp.c0wz.com mirror) _______________________________________________ Leaf-user mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-user
