Long delay before FIN after receiving FIN,ACK from client

Archived from groups: microsoft.public.windowsnt.protocol.tcpip (More info?)

Dave F <Dave F@discussions.microsoft.com> wrote:
> I'm runnnig Win2K on a 1+ GHz 2CPU Dell poweredge, about 10-15% CPU
> load. Networking is quite unloaded. A TCP session finishes up with
> the client sending a FIN,ACK and then server takes upwards of 2
> minutes before responding with its FIN,ACK. I do not believe the
> application code is waiting this long to detect and close the
> socket. Is there some reason why the Windows TCP stack might
> introduce this delay?

Actually, my initial guess would be the application, but to check that
see if you can take a call trace. If it is the stack, it would be the
first time I have ever heard of a stack delaying things that long in
"normal" operation.

rick jones
--
a wide gulf separates "what if" from "if only"
these opinions are mine, all mine; HP might not want them anyway...
feel free to post, OR email to raj in cup.hp.com but NOT BOTH...

Archived from groups: microsoft.public.windowsnt.protocol.tcpip (More info?)

Dave F <DaveF@discussions.microsoft.com> wrote:
> Rick, You were entirely right. There was a path without
> socket.close() and the garbage collector was cleaning it up a few
> minutes later. Thanks. Dave

My pleasure. Always nice to see the intuition working correctly even
as the years advance and bifocals loom large on my horizon While
you are going through the app, you might make sure all the close paths
aren't doing bogus abortive closes.

rick jones
--
denial, anger, bargaining, depression, acceptance, rebirth...
where do you want to be today?
these opinions are mine, all mine; HP might not want them anyway...
feel free to post, OR email to raj in cup.hp.com but NOT BOTH...