| Author |
Terminating Port Connections
|
|
| Peter 2004-03-31, 10:42 am |
| I've run netstat with the following syntax:
netstat -a | grep prog_rpc
The following text is returned:
tcp 0 0 server1.prog_rpc .1127 FIN_WAIT_2
How do I terminate this port connection?
Thanks!
Peter
| |
| joe durusau 2004-03-31, 11:37 am |
|
Peter wrote:
> I've run netstat with the following syntax:
>
> netstat -a | grep prog_rpc
>
> The following text is returned:
>
> tcp 0 0 server1.prog_rpc .1127 FIN_WAIT_2
>
> How do I terminate this port connection?
>
> Thanks!
>
> Peter
It's in the process of terminating. Just wait and it will go away.
Look up the docs on TCP if you want to see why it takes so long.
Speaking only for myself,
Joe Durusau
| |
| bishop@speakeasy.net 2004-03-31, 2:39 pm |
| Peter <patonp@yahoo.com> wrote:
> tcp 0 0 server1.prog_rpc .1127 FIN_WAIT_2
>
> How do I terminate this port connection?
You wait for it to go away.
TCP connections will remain open in a "wait" state for some defined
length of time after the connection is closed. This keeps a subsequent
network connection from attaching to the same port, and receiving any
"stray" packets that were intended for the previous connection (but were
not received before the connection closed).
-Ed
| |
|
| Thanks for the feedback. It looks like there's not much I can do
except wait for the connection to close or re-boot the server.
bishop@speakeasy.net wrote in message news:<7k2dnZMOktfMjvbd38DK-g@speakeasy.net>...
> Peter <patonp@yahoo.com> wrote:
>
> You wait for it to go away.
>
> TCP connections will remain open in a "wait" state for some defined
> length of time after the connection is closed. This keeps a subsequent
> network connection from attaching to the same port, and receiving any
> "stray" packets that were intended for the previous connection (but were
> not received before the connection closed).
>
> -Ed
| |
| bishop@speakeasy.net 2004-04-05, 2:37 pm |
| Peter <patonp@yahoo.com> wrote:
> Thanks for the feedback. It looks like there's not much I can do
> except wait for the connection to close or re-boot the server.
To ease this problem in the future, there may be a kernel parameter
that will shorten the time it will take for this to time out.
Use at your own risk.
-Ed
| |
| Doug Freyburger 2004-04-06, 10:42 am |
| bishop@speakeasy.net wrote:
> Peter wrote:
>
>
> To ease this problem in the future, there may be a kernel parameter
> that will shorten the time it will take for this to time out.
The timeouts in TCP have defaults that assume long latency WAN
connections. IF your host EXCLUSIVELY has local traffic, then
tuning the TCP parameters in the kernel will reduce the time a
closing connection spends in the timeout periods. If your host
does remote WAN traffic, it will hurt performance across the
WAN.
The vast majority of the time, closing connections are purely a
cosmetic issue. Doing this in the kernel is much like getting
a vanity nose job from a plastic surgeon. It puts money in
the surgeon's pocket more than anything else. If you want to
do this, I'll sign up for receiving money from you to guide you
through it ;^)
| |
| bishop@speakeasy.net 2004-04-06, 1:36 pm |
| Doug Freyburger <dfreybur@yahoo.com> wrote:
> The vast majority of the time, closing connections are purely a
> cosmetic issue. Doing this in the kernel is much like getting
> a vanity nose job from a plastic surgeon. It puts money in
> the surgeon's pocket more than anything else. If you want to
> do this, I'll sign up for receiving money from you to guide you
> through it ;^)
Pretty much agreed. Once I did run into a situation where an
application was using a *lot* of network connections between a couple of
servers, and it would end up blocking after a time because the memory
structure for the network connections had filled up with connections
waiting to time out. But that was probably a poorly-written app.
-Ed
|
|
|
|