<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">

<html>

<head>

  <meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">

  <title></title>

</head>

<body bgcolor="#ffffff" text="#000000">

Henrik Stoerner wrote:

<blockquote cite="mid20060405060854.GE9885@hswn.dk" type="cite">

  <pre wrap="">On Tue, Apr 04, 2006 at 06:11:57PM -0500, Jeff Newman wrote:

  </pre>

  <blockquote type="cite">

    <pre wrap="">I'm running Hobbit 4.1.2p1 on a Redhat AS 4 server.

I currently have a number of server side scripts that post-process

incoming test results.

My concern is a high number of "1984" sockets in TIME_WAIT condition

(upwords of 60 on the client at times) The clients are AIX boxes.

    </pre>

  </blockquote>

  <pre wrap=""><!---->

I dont really understand why you see so many TIME_WAIT connections on

the *client*. I could understand if they were on the Hobbit server, but

not on the client...

If there is a firewall between the clients and the server, it could be

that the firewall terminates the connection tracking state before the

final exchange of FIN/ACK packets has completed between the two sides.

But then I'd expect it to be in FIN_WAIT_[1,2] ...

What's TIME_WAIT anyway ... from

<a class="moz-txt-link-freetext" href="http://www.ssfnet.org/Exchange/tcp/tcpTutorialNotes.html:">http://www.ssfnet.org/Exchange/tcp/tcpTutorialNotes.html:</a>

  "The main thing to recognize about connection teardown is that a

   connection in the TIME_WAIT state cannot move to the CLOSED state until

   it has waited for two times the maximum amount of time an IP datagram

   might live in the Inter net. The reason for this is that while the local

   side of the connection has sent an ACK in response to the other side's

   FIN segment, it does not know that the ACK was successfully delivered.

   As a consequence this other side might re transmit its FIN segment, and

   this second FIN segment might be delayed in the network. If the

   connection were allowed to move directly to the CLOSED state, then

   another pair of application processes might come along and open the same

   connection, and the delayed FIN segment from the earlier incarnation of

   the connection would immediately initiate the termination of the later

   incarnation of that connection."

So TIME_WAIT states should only stay around for a few minutes - I

believe a common "2 x max lifetime" is 2 minutes, but this is somewhat

OS dependant. Since the Hobbit client only runs once every 5 minutes,

I don't understand why you have many of these on the clients.

Henrik

To unsubscribe from the hobbit list, send an e-mail to

<a class="moz-txt-link-abbreviated" href="mailto:hobbit-unsubscribe@hswn.dk">hobbit-unsubscribe@hswn.dk</a>

  </pre>

</blockquote>

I just checked a number of hosts here and none of them had anything

like this. About the most I saw was 6 time waits all of which only hung

around for 60 secs maybe 90 tops. Even on both our servers we dont have

any time waits on the hobbit port, only from the client that sends it

stats to the other server but same again minute tops.<br>

<br>

Id suggest the same as what Henrik already has so I won't say any more<br>

<br>

Allan<br>

<br>

</body>

</html>