RE: Pipelining in HTTP 1.1

 

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

Preethi

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