Can a TCP/IP Stack be killed programmatically?

Question

Our server application is listening on a port, and after a period of time it no longer accepts incoming connections. (And while I'd love to solve this issue, it's not what I'm asking about here;)

The strange this is that when our app stops accepting connections on port 44044, so does IIS (on port 8080). Killing our app fixes everything - IIS starts responding again.

So the question is, can an application mess up the entire TCP/IP stack? Or perhaps, how can an application do that?

Senseless detail: Our app is written in C#, under .Net 2.0, on XP/SP2.

Clarification: IIS is not "refusing" the attempted connections. It is never seeing them. Clients are getting a "server did not respond in a timely manner" message (using the .Net TCP Client.)

Answer 1

You may well be starving the stack. It is pretty easy to drain in a high open/close transactions per second environment e.g. webserver serving lots of unpooled requests.

This is exhacerbated by the default TIME-WAIT delay - the amount of time that a socket has to be closed before being recycled defaults to 90s (if I remember right)

There are a bunch of registry keys that can be tweaked - suggest at least the following keys are created/edited

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters

TcpTimedWaitDelay = 30
MaxUserPort = 65534 
MaxHashTableSize = 65536 
MaxFreeTcbs = 16000 

Plenty of docs on MSDN & Technet about the function of these keys.

Answer 2

You haven't maxed out the available port handles have you ?
netstat -a

I saw something similar when an app was opening and closing ports (but not actually closing them correctly).