Re: Lingering Close

I understand the specification of lingering close, however, specifying that
the HTTP implementation should make an effort to ensure that the data is
received before closing (and that lingering close is one such mechanism) is
potentially better.
Lingering close is nasty for a number of reasons.The best option here (at
least for servers) would be to have some knowledge about when the last ack
is ack'd so that it can close the connection from userspace, safe in the
knowledge that everything has arrived at the client safely. That is
obviously not an issue for this WG< however.
-=R


On Wed, Nov 28, 2012 at 9:59 AM, Poul-Henning Kamp <phk@phk.freebsd.dk>wrote:

> --------
> In message <20121128174449.GD7227@1wt.eu>, Willy Tarreau writes:
> >On Wed, Nov 28, 2012 at 11:08:42AM -0600, Zhong Yu wrote:
>
> >The main problem is that HTTP is not well suited for use with TCP (!).
>
> Indeed, this is a major problem in so many ways it's not even funny.
>
> However, considering the penetration of HTTP, it's not inconceivable
> that we could get a couple of much needed extensions to the socket
> API to stick, possibly as a "TCP considerations for HTTP/2.0"
> informal RFC.
>
> If there is interest in this, I can make FreeBSD one of the reference
> implementations.
>
> One extension I have been pondering for a long time, is a true
> per-socket idle timeout (Ie: no data-carrying packets in either
> direction and no outstanding data to transmit for T time)
>
> Poul-Henning
>
> PS: And just in case some of you missed it, Queue had a couple of very
> interesting spotlights on the dark buffer bloat issue some time
> ago:
>
> Article:
>         http://queue.acm.org/detail.cfm?id=2071893
>
> Interview:
>         http://queue.acm.org/detail.cfm?id=2076798
>
> --
> Poul-Henning Kamp       | UNIX since Zilog Zeus 3.20
> phk@FreeBSD.ORG         | TCP/IP since RFC 956
> FreeBSD committer       | BSD since 4.3-tahoe
> Never attribute to malice what can adequately be explained by incompetence.
>
>