How to "kill" a tcp port...

  • Thread starter Thread starter Jako Menkveld
  • Start date Start date
J

Jako Menkveld

I'm building a relatively simple client-server app. One of the functions of
the client is to notify the server when it terminates, this all works fine.
The problem comes in when the server is stopped before the client, in which
case the client "hangs", waiting to talk to the server.

This is how it works:
Server: Starts listening on a tcp port, say 3000 (by registering a
TcpServerChannel and invoking RegisterWellKnownServiceType).
When I shutdown the server, I call the
RemotingServices.Disconnect for the object, then I call StopListening for
the TcpServerChannel and then I call ChannelServices.UnregisterChannel.
Client: When it shutsdown, it gets a reference to the server objecct by
using Activator.GetOjbect and then calls a Notify method. If the server is
still running, the Notify works fine, however, if the server is not running,
the client just "hangs" on the method call (when I debug it using VS, it
never returns from the Notify call and I have to kill the process).

When I do a netstat, it shows that the port the server was listening on is
still in the "LISTENING"-status.

Is there any way of forcefully killing or closing this port?

Any help would really be appreciated!
Thanks
 
Rob

I'll give that a try. Are you saying there is no way of closing the socket
from the Server side then?

Thanks
Jako
 
Jako said:
Rob

I'll give that a try. Are you saying there is no way of closing the socket
from the Server side then?
Click to expand...

1.If the server process (not appdomain) dies without closing the port,
the OS will kill it.

2.TCP itself should give the client an error if the server dies without
closing the connection. Maybe it is ignored by .NET remoting?

What I don't understand is that your netstat shows the port was still
listening after server quit.. Did the server process really quit?
 
Aquila Deus said:
1.If the server process (not appdomain) dies without closing the port,
the OS will kill it.
Click to expand...

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?
Click to expand...

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?
Click to expand...

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.
 
Jako said:
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
Click to expand...
connected. It doesn't make a lot of sense, but that's what seems to happen.

I can really comment on that, once again, I would have expected something
like that to happen, but no luck there either.


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.
Click to expand...

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)
 
Aquila Deus said:
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)
Click to expand...

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.
 
Jako said:
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.
Click to expand...

Uhh.. it may takes a while for the new process to kill the port... Can
you re-produce it?
 
Aquila Deus said:
Uhh.. it may takes a while for the new process to kill the port... Can
you re-produce it?
Click to expand...

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?
 
Jako Menkveld said:
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?
Click to expand...


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?
 
Jako said:
Jako Menkveld said:
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?
Click to expand...


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?
Click to expand...

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).
 
Back
Top