Re: Lingering Close

On Wed, Nov 28, 2012 at 6:29 PM, Willy Tarreau <w@1wt.eu> wrote:
> On Wed, Nov 28, 2012 at 03:13:03PM -0600, Zhong Yu wrote:
>> On Wed, Nov 28, 2012 at 2:22 PM, Willy Tarreau <w@1wt.eu> wrote:
>> > On Wed, Nov 28, 2012 at 01:24:15PM -0600, Zhong Yu wrote:
>> >> Thanks Willy, I think I get what you mean by now. FIN should be
>> >> initiated by server to avoid the TIME_WAIT problem. Therefore the
>> >> half-close step is important.
>> >
>> > exactly.
>> >
>> >> The current text makes perfect sense to me now.
>> >
>> > With this in mind, do you think that something in the text should be
>> > updated for future readers ?
>>
>> The text gives motivation for draining (to avoid RST), it probably
>> should give motivation for half-close as well. The text may become too
>> long and out of scope, but I agree with Jamie Lokier that it's better
>> to warn implementers about the issues.
>
> I too was caught in the past by this and have had to perform several
> incremental changes on haproxy to address this, including for responses
> caught from some servers.
>
>> Also, I would probably use a different word than "linger"; at first
>> read I though it means kernel's lingering.
>
> It was my case too when reading this sentence out of context.
>
> Maybe a small change like this would be appropriate ?
>
>
> -   To avoid the TCP reset problem, a server can perform a lingering
> -   close on a connection by closing only the write side of the read/
> -   write connection (a half-close) and continuing to read from the
> -   connection until the connection is closed by the client or the server
>
> +   To avoid the TCP reset problem, a server can shut down the write side
> +   of the connection (also called a half-close) and continuing to read from
> +   the connection until the connection is closed by the client or the server

"lingering close" is also mentioned in previous texts. give it a new
distinct name?

> Willy
>

Received on Thursday, 29 November 2012 02:11:40 UTC