W3C home > Mailing lists > Public > ietf-http-wg-old@w3.org > September to December 1995

Re: Persistent connections: aborting requests in progress.

From: Paul Leach <paulle@microsoft.com>
Date: Tue, 12 Sep 95 11:10:50 PDT
Message-Id: <9509121933.AA08581@netmail2.microsoft.com>
To: mogul@pa.dec.com
Cc: http-wg%cuckoo.hpl.hp.com@hplb.hpl.hp.com

Jeff said:
] Paul said:
]     It also needs a way to interleave responses from the pipelined
]     requests, else long ones will delay shorter ones. Think about the
]     concurrent "progressive rendering" of multiple GIF and JPEG files that
]     currently is done using multiple connections, and what it would take to
]     do it with pipelining.
] As Simon has already pointed out, HTTP-NG (which may end being called
] HTTP 2.0, I guess) already proposes mechanisms to get away from a simple
] byte-stream model.  I think this is probably too much of a jump for
] HTTP 1.x.
] Further, I think "needs" is too strong a word.  If one measures
] the total latency to retrieve and fully render a page with inlined
] images, a single persistent HTTP connection will almost always
] finish faster than N separate single-request TCP connections.  So
] even without interleaved responses, P-HTTP would be "faster" in
] this sense than what we have today.

Of course. One only "needs" interleaved responses to take full 
advantage of pipelining.

In order of goodness, I would think one could order the protocols as follows:
1. Today -- 1 connection per request
2. persistent connections
3. persistent connections with pipelining
4. persistent connections with pipelining with interleaved responses.

The distinction between #2 and #3 may be somewhat artificial. In the 
sense that even if one didn't define pipelining in the protocol, one 
could still do it in the following way:
a. Send request
b. Receive first buffer(s) of response; enough to see that no further 
negotiation (e.g., authentication) or other packet exchanges are 
required for this request.
c. Send next request (perhaps based on the contents of the immediatelty 
or some other previous response)
And a proper, timing independent, implementation would accept it and 
process it correctly -- it wouldn't necessarily even notice that the 
second request was sent before the first had completed.

Received on Tuesday, 12 September 1995 11:41:52 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 7 January 2015 14:40:15 UTC