Mailing-List: contact commons-httpclient-dev-help@jakarta.apache.org;
 run by ezmlm
Precedence: bulk
Reply-To: "Commons HttpClient Project"
 <commons-httpclient-dev@jakarta.apache.org>
Message-ID: <3F8669B4.6060209@nose.ch>
Date: Fri, 10 Oct 2003 10:11:32 +0200
From: =?ISO-8859-1?Q?Ortwin_Gl=FCck?= <ortwin.glueck@nose.ch>
Organization: NOSE Applied Intelligence
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US;
 rv:1.5) Gecko/20030925
MIME-Version: 1.0
To: Commons HttpClient Project <commons-httpclient-dev@jakarta.apache.org>
Subject: Re: MultiThreadedHttpConnectionManager question
References: 
 <825BF35A92B3F0479CC164ECBBE9376E0DE62A@kccxoex06.corp.kpmgconsulting.com>
In-Reply-To: 
 <825BF35A92B3F0479CC164ECBBE9376E0DE62A@kccxoex06.corp.kpmgconsulting.com>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit


Kalnichevski, Oleg wrote:

> Odi,
> If there's enough confidence that setting linger time to 0 will not have an unexpected adverse effect, the fix can be included into 2.0. I do not know TCP/IP that well to make that call, though.
> 
> Oleg 


 From RFC-739 3.5:

  When a connection is closed actively, it MUST linger in TIME-WAIT 
state for a time 2xMSL (Maximum Segment Lifetime). However, it MAY 
accept a new SYN from the remote TCP to reopen the connection directly 
from TIME-WAIT state, if it:

    1. assigns its initial sequence number for the new connection to be 
larger than the largest sequence number it used on the previous 
connection incarnation, and

    2. returns to TIME-WAIT state if the SYN turns out to be an old 
duplicate.


Some more information on what setSoLinger() does:

   Specify a linger-on-close timeout. This option disables/enables 
immediate return from a close() of a TCP Socket. Enabling this option 
with a non-zero Integer timeout means that a close() will block pending 
the transmission and acknowledgement of all data written to the peer, at 
which point the socket is closed gracefully. Upon reaching the linger 
timeout, the socket is closed forcefully, with a TCP RST. Enabling the 
option with a timeout of zero does a forceful close immediately.


 From the kernel archives:

Setting linger to zero to zap time waiters is not only anti-social,
the various IP working groups state that it is strongly discouraged
upon, both in the RFC's and elsewhere. The TIME_WAIT state was
created for a specific purpose, by zapping the socket before the
TIME_WAIT timeout occurs you are defeating the purpose of it.

Even FreeBSD's stack has this old linger==0 behavior totally removed.


So I guess setting SO_LINGER to zero could:

a) not work at all
b) have adverse effects on reliability (possible data loss in the last 
packet)

I am not an expert on TCP either, so maybe someone with indepth 
knowledge about the close handshake could advise us what to do here. 
It's certainly not something that should go into 2.0 though. Just too risky.


---------------------------------------------------------------------
To unsubscribe, e-mail: commons-httpclient-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-httpclient-dev-help@jakarta.apache.org