473,218 Members | 1,882 Online
Bytes | Software Development & Data Engineering Community
Post Job

Home Posts Topics Members FAQ

Join Bytes to post your question to a community of 473,218 software developers and data experts.

How to "kill" a tcp port...

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
Jul 21 '05 #1
10 6101
Thread it and terminate thread if call is taking too long.

Rob.

"Jako Menkveld" <ja***********@envalue.ch> wrote in message
news:uk**************@TK2MSFTNGP15.phx.gbl...
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

Jul 21 '05 #2
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

"Rob R. Ainscough" <ro*****@pacbell.net> wrote in message
news:eL**************@TK2MSFTNGP15.phx.gbl...
Thread it and terminate thread if call is taking too long.

Rob.

"Jako Menkveld" <ja***********@envalue.ch> wrote in message
news:uk**************@TK2MSFTNGP15.phx.gbl...
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


Jul 21 '05 #3
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.

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?

Jul 21 '05 #4
"Aquila Deus" <aq*********@gmail.com> wrote in message
news:11**********************@g14g2000cwa.googlegr oups.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.
Jul 21 '05 #5
Jako Menkveld wrote:
"Aquila Deus" <aq*********@gmail.com> wrote in message
news:11**********************@g14g2000cwa.googlegr oups.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)

Jul 21 '05 #6
"Aquila Deus" <aq*********@gmail.com> wrote in message
news:11*********************@o13g2000cwo.googlegro ups.com...
Jako Menkveld wrote:
"Aquila Deus" <aq*********@gmail.com> wrote in message
news:11**********************@g14g2000cwa.googlegr oups.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.
Jul 21 '05 #7
Jako Menkveld wrote:
"Aquila Deus" <aq*********@gmail.com> wrote in message
news:11*********************@o13g2000cwo.googlegro ups.com...
Jako Menkveld wrote:
"Aquila Deus" <aq*********@gmail.com> wrote in message
news:11**********************@g14g2000cwa.googlegr oups.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?

Jul 21 '05 #8
"Aquila Deus" <aq*********@gmail.com> wrote in message
news:11**********************@c13g2000cwb.googlegr oups.com...
Jako Menkveld wrote:
"Aquila Deus" <aq*********@gmail.com> wrote in message
news:11*********************@o13g2000cwo.googlegro ups.com...
> Jako Menkveld wrote:
>> "Aquila Deus" <aq*********@gmail.com> wrote in message
>> news:11**********************@g14g2000cwa.googlegr oups.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?
Jul 21 '05 #9

"Jako Menkveld" <ja***********@envalue.ch> wrote in message
news:uM*************@TK2MSFTNGP15.phx.gbl...
"Aquila Deus" <aq*********@gmail.com> wrote in message
news:11**********************@c13g2000cwb.googlegr oups.com...
Jako Menkveld wrote:
"Aquila Deus" <aq*********@gmail.com> wrote in message
news:11*********************@o13g2000cwo.googlegro ups.com...
> Jako Menkveld wrote:
>> "Aquila Deus" <aq*********@gmail.com> wrote in message
>> news:11**********************@g14g2000cwa.googlegr oups.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?
Jul 21 '05 #10
Jako Menkveld wrote:
"Jako Menkveld" <ja***********@envalue.ch> wrote in message
news:uM*************@TK2MSFTNGP15.phx.gbl...
"Aquila Deus" <aq*********@gmail.com> wrote in message
news:11**********************@c13g2000cwb.googlegr oups.com...
Jako Menkveld wrote:
"Aquila Deus" <aq*********@gmail.com> wrote in message
news:11*********************@o13g2000cwo.googlegro ups.com...
> Jako Menkveld wrote:
>> "Aquila Deus" <aq*********@gmail.com> wrote in message
>> news:11**********************@g14g2000cwa.googlegr oups.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).

Jul 21 '05 #11

This thread has been closed and replies have been disabled. Please start a new discussion.

Similar topics

10
by: Fred | last post by:
There is a setting in INIT.ORA that has the unintended side-effect of making sure the ALTER SYSTEM KILL SESSION command has immediate affect. Without this setting, I've seen some instances where...
10
by: Jako Menkveld | last post by:
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...
1
by: =?Utf-8?B?QWxoYW1icmEgRWlkb3MgS2lxdWVuZXQ=?= | last post by:
Hi misters, Is it possible "kill" the thread of Backgroundworker ? In my Dowork event, I have NOT While for do e.Cancel = true, only have a call to external COM. If I want cancel, calling...
1
isladogs
by: isladogs | last post by:
The next online meeting of the Access Europe User Group will be on Wednesday 6 Dec 2023 starting at 18:00 UK time (6PM UTC) and finishing at about 19:15 (7.15PM). In this month's session, Mike...
0
by: veera ravala | last post by:
ServiceNow is a powerful cloud-based platform that offers a wide range of services to help organizations manage their workflows, operations, and IT services more efficiently. At its core, ServiceNow...
3
isladogs
by: isladogs | last post by:
The next Access Europe meeting will be on Wednesday 3 Jan 2024 starting at 18:00 UK time (6PM UTC) and finishing at about 19:15 (7.15PM). For other local times, please check World Time Buddy In...
0
by: mar23 | last post by:
Here's the situation. I have a form called frmDiceInventory with subform called subfrmDice. The subform's control source is linked to a query called qryDiceInventory. I've been trying to pick up the...
0
by: abbasky | last post by:
### Vandf component communication method one: data sharing ​ Vandf components can achieve data exchange through data sharing, state sharing, events, and other methods. Vandf's data exchange method...
2
by: jimatqsi | last post by:
The boss wants the word "CONFIDENTIAL" overlaying certain reports. He wants it large, slanted across the page, on every page, very light gray, outlined letters, not block letters. I thought Word Art...
0
by: fareedcanada | last post by:
Hello I am trying to split number on their count. suppose i have 121314151617 (12cnt) then number should be split like 12,13,14,15,16,17 and if 11314151617 (11cnt) then should be split like...
0
by: stefan129 | last post by:
Hey forum members, I'm exploring options for SSL certificates for multiple domains. Has anyone had experience with multi-domain SSL certificates? Any recommendations on reliable providers or specific...
1
by: davi5007 | last post by:
Hi, Basically, I am trying to automate a field named TraceabilityNo into a web page from an access form. I've got the serial held in the variable strSearchString. How can I get this into the...

By using Bytes.com and it's services, you agree to our Privacy Policy and Terms of Use.

To disable or enable advertisements and analytics tracking please visit the manage ads & tracking page.