Re: Lingering Close

On Wed, Nov 28, 2012 at 05:59:14PM +0000, Poul-Henning Kamp 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.

I agree. We've also discussed about this with Roberto Peon at IETF83 in
Paris and it seems we are several HTTP implementors to have ideas about
missing things (such as polling for all sent data to be acked, "true"
lingering close, etc...). Being able to pass a FIN with a full window
along the path would be nice too, as well as detecting it without polling
for reads.  Having recv() report the received shutdown without performing
a second attemtp would also help for the vast majority of situations where
the response comes with a close, etc... Well, that's a complete discussion
out of scope for this WG.

> If there is interest in this, I can make FreeBSD one of the reference
> implementations.

That could be an idea, yes.

> 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)

Indeed, that's one thing that could help.

> 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

I'll check this, thanks !

Willy

Received on Wednesday, 28 November 2012 18:14:15 UTC