Re: Pipelining in HTTP 1.1

Roy T. Fielding wrote:
> or even extend HTTP
> such that the request/response contains some form of matching ID.

I did this in an application-specific extension of HTTP, and learned
something not obvious to me.

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.

Unfortunately BEEP is a bit heavy as it stands for extending HTTP like
this, because BEEP relies on XML, and because the channel setup cost
is not particularly cheap either in bytes or round trips.

In my own extended-HTTP-like, I've adopted "fire and forget" lazy
stream creation whenever a new request is sent, subject to flow
control for the transport stream as a whole (window of max requests in
flight) and per channel (window of bytes in flight per channel, no
window required when there's only one in flight).  It sounds like the
SCTP negotiated number of channels is similar, especially with the
extension to let that number be increased.

-- Jamie

Received on Wednesday, 1 April 2009 10:24:36 UTC