W3C home > Mailing lists > Public > ietf-http-wg@w3.org > April to June 2009

RE: Pipelining in HTTP 1.1

From: Preethi Natarajan (prenatar) <prenatar@cisco.com>
Date: Wed, 1 Apr 2009 17:27:52 -0400
Message-ID: <C14B21C3CFBE6F4C81665B29F9880D3E0760656E@xmb-rtp-214.amer.cisco.com>
To: "Jamie Lokier" <jamie@shareable.org>, "Roy T. Fielding" <fielding@gbiv.com>
Cc: <ietf-http-wg@w3.org>, "Jonathan Leighton" <leighton@cis.udel.edu>, "Paul D. Amer" <amer@cis.udel.edu>, "Fred Baker (fred)" <fred@cisco.com>

> -----Original Message-----
> From: Jamie Lokier [mailto:jamie@shareable.org] 
> Sent: Wednesday, April 01, 2009 3:24 AM
> To: Roy T. Fielding
> Cc: Preethi Natarajan (prenatar); ietf-http-wg@w3.org; 
> Jonathan Leighton; Paul D. Amer; Fred Baker (fred)
> Subject: Re: Pipelining in HTTP 1.1
> Beware if you allow reordering and really use it, you can get 
> into deadlock or unbounded-buffer-needed scenarios, unless 
> you also implement some kind of per-ID flow control.
> I found interleaving HTTP-style chunks, labelled with a 
> request-response ID, and per ID receive windows, works well.  
> Many of the annoying problems of HTTP pipelining go away.
> However, without per-ID flow control, if a process consuming 
> one of the requests or responses stalls, it forces all the 
> others to stall too.  This is because the other only flow 
> control signal is the TCP receive window closing, which 
> blocks the whole transport.
> BEEP over TCP shows how to solve this, though the spec leaves 
> you to figure out for yourself why.  BEEP itself is a 
> protocol to multiplex logical streams over a single transport 
> stream.  The BEEP over TCP spec adds a bit more syntax, so 
> each logical stream advertises its own independent receive 
> window.  This prevents a single slow process from stalling 
> the streams of others.

I assume by "stall" you mean that the transport is ready to deliver data
but the application process is busy doing something else. 

If yes, wouldn't this problem go away when a single thread/process reads
data from the socket and moves the data to appropriate response buffers
(as done in Firefox) instead of multiple threads/processes, one per
response, reading from the socket? 

Still, I think that the BEEP approach would suffer from head-of-line
blocking during packet losses, which is what SCTP streams solve. In
BEEP, the logical streams are multiplexed over a single TCP bytestream
-- if a TCP PDU is lost, successive TCP PDUs (belonging to different
responses) will not be delivered to BEEP/app. 

Received on Wednesday, 1 April 2009 21:28:35 UTC

This archive was generated by hypermail 2.4.0 : Thursday, 2 February 2023 18:43:19 UTC