TCP ESTABLISHED status even after network cable unplugged

I have an application that establishes a socket connection w/ another application on a different machine. When this connection is disrupted (e.g., pull out network cable), I recognize this condition and take some action.

In a Windows XP 32-bit environment, this happens quickly ... in seconds.

In a Windows 7 64-bit environment, this happens slowly ... in about 5 minutes.

If I run netstat in the W7 environment, the TCP connection shows ESTABLISHED for about 5 minutes after the network cable has been unplugged. (In WXP, it changes in seconds.)

I've searched the forum and have heard a few people refer to 5 minutes as being a "default" timeout value. I've also looked at the TCP spec, etc. to learn a bit more, understand it better, etc. in an attempt to find something I can configure to reduce the 5 minutes to seconds but I've not run into anything yet.

Ideas?

Thanks!
Kelly

I found documentation for a registry entry named TcpTimedWaitDelay for the TCP/IP service. It describes the default to be 240 seconds (4 minutes) and suggests it be set to 30.

In the W7 environment, this entry was not set so I added it and restarted the machine. This did not work.

Be sure to backup your registry before attempting any modifications blablabla.

Did you modify this one?

Code:

Windows Registry Editor Version 5.00

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\services\Tcpip\Parameters]
"TcpTimedWaitDelay"=dword:0000001e

(it's in hexa)


If that doesn't work I've searched for a tool that will let you close a TCP connection. I've found wKillcx : close a TCP connection (for Windows)

Thanks for the reply. Yes, that was the registry entry I modified and it did not help.

I'm not sure the tool would help me and my situation. My application doesn't know the connection needs to or can be closed. It makes a call and in Window XP returns almost immediately if the cable has been unplugged but not in Windows 7. The end user experience of the application is expected to be ... when the network connection is lost, notify the user and take them offline which allows them to perform a subset of functions. The problem is in W7 because it takes so long to detect this that in the meantime the user tries to perform functions that require network access.

I've tried to take my application out of the loop by monitoring netstat output. Once my application creates the socket and I unplug the cable, in WXP the socket connection disappears from the netstat list whereas in W7 it remains as ESTABLISHED for about 5 minutes. Therefore, my conclusion is that it has nothing to do w/ my application per se but some difference between WXP and W7 or the network configuration.

Ah, I see. Well, that didn't work because TcpTimedWaitDelay is used for connections in the TIME_WAIT state not the ESTABLISHED state.

Imo*, I'd start by making a new method of detecting disrupted connections and take it from there. It's a one-time modification ('til Windows 8 comes out ) whereas modifying every PC you put your application on is not a one-time modification and could cause other problems unrelated to your application.

If you really want to go down the road with the registry change, here, read this: TCP/IP config. parameters I'm guessing that's your best bet.



__________
* in my oppinion.

Thanks for the advice. I started to think if what you just suggested is my only viable option. It just bugs me though that I can't find a reasonable explanation for the change in behavior.

The change is probably for reliability.
For example, let's say you're downloading a file and the connection breaks. And the example application is set to
a) cancel the download if the connection disappears
and b) keep retrying if the connection is still established.

This application will behave like this:
On WinXP, your download is canceled and you lose all your downloaded data.
On Win7, the example app keeps retrying until the connection resumes or the timeout expires. If it succeeds, the download is resumed.

That's one thing I could think of. Hope it kinda explains the change in behavior.