On 10 Feb 2008, at 14:09, Andreas Veithen wrote:
More precisely, the given combination of (local address, local
port, remote address, remote port) cannot be reused. Since local
address, remote address and remote port are fixed this still leaves
more than 60000 possible combinations. Assuming that connections
remain in state TIME_WAIT for 240 seconds, you would have to open
(and close) connections every 4 milliseconds to hit the limit. Some
systems by default don't use the full available port range, so the
figures might be a bit different, but anyway, at this connection
rate the TCP transport seems not very appropriate and should be
replaced by something more sophisticated like HTTP (with keepalive)
or JMS.
Maybe it is useful to come back to the initial question asked in
this thread:
"Hello, I'm using a stub that is connecting the server using TCP
transport. I'm looping around calling the service operation.
After I'm done I run netstat -na and I see a whole lot of
connections in TIME_WAIT. Can I instruct the stub to clean up the
connection after a method call?"
The complete answer to this question is as follows:
1) It is normal to see connections in state TIME_WAIT. This is not
an indication of failure of the client to clean up connections, but
is required by the TCP protocol.
2) Having large numbers of connections in state TIME_WAIT is not a
problem in itself.
3) If a single client opens and closes more than about 100
connections per second, this leads to exhaustion of local ports on
the client side. If this is the case, consider using a different
transport.
A possible solution to problem #3 would be to customize some kernel
settings (/etc/sysctl.conf), such as
net.ipv4.tcp_fin_ack_timeout
net.ipv4.tcp_keepalive_time
Michele
Regards,
Andreas
On 10 Feb 2008, at 12:18, Michele Mazzucco wrote:
Andreas,
the point is that while the connection is in TIME_WAIT state the
socket cannot be reused (see the links below).
Michele
http://www.port80software.com/200ok/archive/2004/12/07/205.aspx
http://msdn2.microsoft.com/en-us/library/aa560610.aspx
On 9 Feb 2008, at 20:59, Andreas Veithen wrote:
On 09 Feb 2008, at 19:52, Michele Mazzucco wrote:
This is not a problem, since in this state, no resources (other
than the corresponding entries in some internal OS data
structure and that you can see with netstat) are consumed
whatsoever.
This might be a problem, since they increase the number of open
file (& connections). Remember that by default linux allows only
1024 open files.
A connection in state TIME_WAIT is closed (no further packets
will be sent and no packets except "wandering" packets are
expected to be received). Therefore there is no file descriptor
associated to it.
Andreas
--------------------------------------------------------------------
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
