Re: pipelined client/server behaviour

On Apr 1, 2007, at 8:06 AM, Jamie Lokier wrote:
> The main problem with pipelining is that a large or slow response
> delays subsequent responses.  Sometimes the delay can be very long,
> especially for a response generated on the fly.  Sometimes a response
> is a stream which does not terminate.

I would say that is one negative result of pipelining.  There can
be positive results as well, particularly when the client remembers
which servers do support pipelining.  But there is no question that
pipelining is hard to do right across all implementations.  That
doesn't mean it can't be done across some implementations, and there
really isn't much point in discussing it -- the standard will not
be changed.

<rant>The real problem with HTTP pipelining, though, is that it is
a horrible idea to try to duplicate TCP at the application layer.
If the people-in-charge hadn't been in such a hurry to blame HTTP
for everything bad happening to the Internet in 1994, they would
probably have realized that it made far more sense to fix
the semantic errors in TCP that prevent the sharing of window
sizes and setup information across multiple connections from the
same peers.  Sure, it would have taken some time to deploy such
a change across enough servers for it to make a difference, but
it would have fixed all sorts of denial-of-service vulnerabilities
at the same time as removing the need for HTTP to get into the
business of connection management, MUXing, etc.  TCP is a hard
problem that should only be solved once in the stack.</rant>

....Roy

Received on Sunday, 1 April 2007 17:25:53 UTC