Re: How to "kill" a tcp port...

Tech-Archive recommends: Fix windows errors by optimizing your registry

From: Aquila Deus (aquila.deus_at_gmail.com)
Date: 02/05/05 

Date: 4 Feb 2005 18:02:32 -0800

Jako Menkveld wrote:
> "Jako Menkveld" <jako.menkveld@envalue.ch> wrote in message
> news:uMDuFCsCFHA.464@TK2MSFTNGP15.phx.gbl...
> > "Aquila Deus" <aquila.deus@gmail.com> wrote in message
> > news:1107517282.094241.243710@c13g2000cwb.googlegroups.com...
> >> Jako Menkveld wrote:
> >>> "Aquila Deus" <aquila.deus@gmail.com> wrote in message
> >>> news:1107515348.466168.11710@o13g2000cwo.googlegroups.com...
> >>> > Jako Menkveld wrote:
> >>> >> "Aquila Deus" <aquila.deus@gmail.com> wrote in message
> >>> >> news:1107512389.581833.316910@g14g2000cwa.googlegroups.com...
> >>> >> > Jako Menkveld wrote:
> >>> >> >> Rob
> >>> >> >>
> >>> >> >> I'll give that a try. Are you saying there is no way of
> >> closing
> >>> > the
> >>> >> > socket
> >>> >> >> from the Server side then?
> >>> >> >
> >>> >> > 1.If the server process (not appdomain) dies without closing
the
> >>> > port,
> >>> >> > the OS will kill it.
> >>> >>
> >>> >> I also thought this would be the case, but for some reason the
OS
> >>> > (Win XP by
> >>> >> the way), keeps the connection open because the client-side
was
> >> still
> >>> >
> >>> >> connected. It doesn't make a lot of sense, but that's what
seems
> >> to
> >>> > happen.
> >>> >>
> >>> >> >
> >>> >> > 2.TCP itself should give the client an error if the server
dies
> >>> > without
> >>> >> > closing the connection. Maybe it is ignored by .NET
remoting?
> >>> >>
> >>> >> I can really comment on that, once again, I would have
expected
> >>> > something
> >>> >> like that to happen, but no luck there either.
> >>> >>
> >>> >> >
> >>> >> > What I don't understand is that your netstat shows the port
was
> >>> > still
> >>> >> > listening after server quit.. Did the server process really
> >> quit?
> >>> >> >
> >>> >>
> >>> >> The server process did die (can't see it in Task Manager for
any
> >>> > user). The
> >>> >> interesting thing is that if I run netstat -o and get the
process
> >> ID
> >>> > of the
> >>> >> listener, I can't find that process ID in Task Manager either
and
> >> it
> >>> > is
> >>> >> different from the original server's process ID.
> >>> >
> >>> > And what's the name of the new process that took the port?
Maybe
> >>> > windows needs to launch another program to kill unclosed port
(just
> >>> > like how it kills apps forcefully)
> >>> >
> >>>
> >>> I'm not sure what the name is, but it seems like Windows launches
> >> another
> >>> process to keep the port open, rather than kill it.
> >>
> >> Uhh.. it may takes a while for the new process to kill the port...
Can
> >> you re-produce it?
> >>
> >
> > Not right now, but I should be able to do that again. Is there
something
> > I need to look out for and let you know what happened?
> >
>
>
> I reproduced it and ran a more detailed netstat.
>
> The process ID is still one I can't find in Task Manager and the
executable
> responsible for the open port is displayed as "[System]". The
components
> involved in creating the connection is displayed as "-- unknown
> component(s) --". Most of the other connections in the netstat list
shows
> actual executable and component names.
>
> Does this help at all?

Yep, that means the OS has taken the unclosed port, and we have better
to stop here. Now it's time to track the client-side. Maybe you should
also report it as a bug to M$ (i dunno where to do so though).

Relevant Pages

  • Re: How to "kill" a tcp port...
    ... Jako Menkveld wrote: ... Yep, that means the OS has taken the unclosed port, and we have better ...
    (microsoft.public.dotnet.general)
  • Re: How to "kill" a tcp port...
    ... Jako Menkveld wrote: ... Yep, that means the OS has taken the unclosed port, and we have better ...
    (microsoft.public.dotnet.framework)