Re: Lingering Close

On Wed, Nov 28, 2012 at 12:20:06PM -0600, Zhong Yu wrote:
> Willy, I thought the term "lingering closed" in the section is self-defined
> 
>     a server can perform a lingering close on a connection by [steps...]
> 
> the word linger here has nothing to do with its usage elsewhere, like
> SO_LINGER option.

OK.

> I might be wrong if the word "linger" carries a meaning not defined
> here but well known to the readers. Please clarify. At least the word
> is not in the TCP spec.

No, you're right.

> Regardless, I certainly do not suggest to abortively close a
> connection without seeing outbound data ACK-ed. My point is, the
> half-close step is not necessary.

I disagree, precisely because if you only close, you risk facing
the RST.

> > No, there are several issues with this, among which :
> >   - bogus clients which still send a late CRLF after a POST will trigger
> >     an immediate reset from the server's TCP stack before the end of the
> >     transfer if the connection is closed without lingering. This results
> >     in the common problem of truncated responses ;
> 
> It's solved by the draining step, not by half-close

No, because if you don't send the half-close, you can't expect the client
to close first as it might very well be only relying on the close to get
the end of the message (old client). Also, even if it's a new client, you
absolutely don't want it to close first as you might cause it to run out
of source ports very quickly (think about a proxy).

> >   - "lingering" here clearly means the work performed by the TCP stack
> >     which is performed by default. If we remove this and talk about
> >     just a close, some people will believe that they can explicitly
> >     disable lingering, which is totally wrong as this also kills all
> >     pending data and truncates the response as well.
> 
> I do not suggest to disable "lingering" in that sense.

OK.

> > The main problem is that HTTP is not well suited for use with TCP (!).
> > But we have it now and we must do whatever we can to maximize chances of
> > successful transfers. The two problems of TCP are :
> >   - application is not aware that the remote end has received everything.
> >     An application-level ACK from the client would have solved this ;
> >
> >   - client must never be encouraged to close first otherwise it quickly
> >     faces the 2 MSL problem with sockets in TIME-WAIT and cannot open new
> >     ports for several minutes whatever the setsockopt() it did. Still,
> >     sometimes we don't have much choice.
> >
> >>   2. Some APIs do not support half-close. Examples in Java: SSL
> >> socket, Netty channel.
> >
> > Then these ones most likely perform the half-close transparently for you,
> > and certainly don't disable lingering!
> 
> It's impossible in these APIs to half-close first, then read;
> therefore the current description of "lingering close" cannot be
> implemented in these APIs.

But I do think that if you simply close, the underlying layers will do
the lingering for you. However this still means that these APIs are not
compatible with HTTP/1.0 clients, which is somewhat problematic :-/

Willy

Received on Wednesday, 28 November 2012 19:08:32 UTC