<?xml version="1.0" encoding="UTF-8"?>
<rss xmlns:content="http://purl.org/rss/1.0/modules/content/" xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#" xmlns:taxo="http://purl.org/rss/1.0/modules/taxonomy/" version="2.0">
  <channel>
    <title>topic networking fin_wait_2 in Operating System - HP-UX</title>
    <link>https://community.hpe.com/t5/operating-system-hp-ux/networking-fin-wait-2/m-p/4120994#M540488</link>
    <description>Hi,&lt;BR /&gt;&lt;BR /&gt;fin_wait_2_timeout is defined as 0 on one of the servers rp8420 OS version 11.11. currently there are ~1600 connections in fin_wait_2 status. &lt;BR /&gt;is there any limit in connections ?&lt;BR /&gt;is there any infuence from any kind on the performance of the server ?&lt;BR /&gt;&lt;BR /&gt;please advise,&lt;BR /&gt;&lt;BR /&gt;thanks,&lt;BR /&gt;&lt;BR /&gt;Reuven&lt;BR /&gt;</description>
    <pubDate>Wed, 26 Dec 2007 10:54:30 GMT</pubDate>
    <dc:creator>System Unix</dc:creator>
    <dc:date>2007-12-26T10:54:30Z</dc:date>
    <item>
      <title>networking fin_wait_2</title>
      <link>https://community.hpe.com/t5/operating-system-hp-ux/networking-fin-wait-2/m-p/4120994#M540488</link>
      <description>Hi,&lt;BR /&gt;&lt;BR /&gt;fin_wait_2_timeout is defined as 0 on one of the servers rp8420 OS version 11.11. currently there are ~1600 connections in fin_wait_2 status. &lt;BR /&gt;is there any limit in connections ?&lt;BR /&gt;is there any infuence from any kind on the performance of the server ?&lt;BR /&gt;&lt;BR /&gt;please advise,&lt;BR /&gt;&lt;BR /&gt;thanks,&lt;BR /&gt;&lt;BR /&gt;Reuven&lt;BR /&gt;</description>
      <pubDate>Wed, 26 Dec 2007 10:54:30 GMT</pubDate>
      <guid>https://community.hpe.com/t5/operating-system-hp-ux/networking-fin-wait-2/m-p/4120994#M540488</guid>
      <dc:creator>System Unix</dc:creator>
      <dc:date>2007-12-26T10:54:30Z</dc:date>
    </item>
    <item>
      <title>Re: networking fin_wait_2</title>
      <link>https://community.hpe.com/t5/operating-system-hp-ux/networking-fin-wait-2/m-p/4120995#M540489</link>
      <description>Hi Reuven&lt;BR /&gt;&lt;BR /&gt;From official docs &lt;BR /&gt;TCP FIN WAIT 2 Timer&lt;BR /&gt;&lt;BR /&gt;The ndd TCP parameter tcp_fin_wait_2 determines how long a TCP connection will be in FIN_WAIT_2.&lt;BR /&gt;&lt;BR /&gt;Normally one end of a connection initiates the close of its end of the connection (indicates that it has no more data to send) by sending a FIN. When the remote TCP acknowledges the FIN, TCP goes to the FIN_WAIT_2 state and will remain in that state until the remote TCP sends a FIN.&lt;BR /&gt;&lt;BR /&gt;If the FIN_WAIT_2 timer is used, TCP will close the connection when it has remained in the FIN_WAIT_2 state for the length of the timer value.&lt;BR /&gt;&lt;BR /&gt;The FIN_WAIT_2 timer must be used with caution because when TCP is in the FIN_WAIT_2 state the remote is still allowed to send data. In addition, if the remote TCP would terminate normally (it is not hung nor terminating abnormally) and the connection is closed because of the FIN_WAIT_2 timer, the connection may be closed prematurely.&lt;BR /&gt;&lt;BR /&gt;Data may be lost if the remote sends a window update or FIN after the local TCP has closed the connection. In this situation, the local TCP will send a RESET. According to the TCP protocol specification, the remote TCP should flush its receive queue when it receives the RESET. This may cause data to be lost.&lt;BR /&gt;&lt;BR /&gt;Default: 0 (indefinite)&lt;BR /&gt;&lt;BR /&gt;Range: 0 - 2147483647&lt;BR /&gt;&lt;BR /&gt;Units: Milliseconds&lt;BR /&gt;&lt;BR /&gt;So you should query why your clients send RESET to server instead of FIN?. &lt;BR /&gt;&lt;BR /&gt;Each FIN_WAIT_2 connection needs memory so you can define a timeout value with ndd&lt;BR /&gt;&lt;BR /&gt;Best Regards&lt;BR /&gt;Murat&lt;BR /&gt;&lt;BR /&gt;&lt;BR /&gt;</description>
      <pubDate>Wed, 26 Dec 2007 19:10:39 GMT</pubDate>
      <guid>https://community.hpe.com/t5/operating-system-hp-ux/networking-fin-wait-2/m-p/4120995#M540489</guid>
      <dc:creator>Murat SULUHAN</dc:creator>
      <dc:date>2007-12-26T19:10:39Z</dc:date>
    </item>
    <item>
      <title>Re: networking fin_wait_2</title>
      <link>https://community.hpe.com/t5/operating-system-hp-ux/networking-fin-wait-2/m-p/4120996#M540490</link>
      <description>thanks Murat :-)&lt;BR /&gt;&lt;BR /&gt;Reuven</description>
      <pubDate>Wed, 26 Dec 2007 21:26:53 GMT</pubDate>
      <guid>https://community.hpe.com/t5/operating-system-hp-ux/networking-fin-wait-2/m-p/4120996#M540490</guid>
      <dc:creator>System Unix</dc:creator>
      <dc:date>2007-12-26T21:26:53Z</dc:date>
    </item>
    <item>
      <title>Re: networking fin_wait_2</title>
      <link>https://community.hpe.com/t5/operating-system-hp-ux/networking-fin-wait-2/m-p/4120997#M540491</link>
      <description>If there is no more socket associated with each of those FIN_WAIT_2 connections, the tcp_keepalive_detached_interval stuff, should (IIRC) be culling those connections, unless there is still a TCP endpoint at the other end, responding to the keepalive probes...</description>
      <pubDate>Mon, 31 Dec 2007 19:26:11 GMT</pubDate>
      <guid>https://community.hpe.com/t5/operating-system-hp-ux/networking-fin-wait-2/m-p/4120997#M540491</guid>
      <dc:creator>rick jones</dc:creator>
      <dc:date>2007-12-31T19:26:11Z</dc:date>
    </item>
    <item>
      <title>Re: networking fin_wait_2</title>
      <link>https://community.hpe.com/t5/operating-system-hp-ux/networking-fin-wait-2/m-p/4120998#M540492</link>
      <description>tnx, Rick</description>
      <pubDate>Tue, 01 Jan 2008 06:41:51 GMT</pubDate>
      <guid>https://community.hpe.com/t5/operating-system-hp-ux/networking-fin-wait-2/m-p/4120998#M540492</guid>
      <dc:creator>System Unix</dc:creator>
      <dc:date>2008-01-01T06:41:51Z</dc:date>
    </item>
  </channel>
</rss>

