Re: Persistent connections: aborting requests in progress.

    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.
    
This is, in fact, exactly what Venkat Padmanabhan implemented for me
last summer, except that we skipped step (b).  That is, we just dumped
all the requests into the connection, without any attempt to see if
negotiation is required.  Presumably, the first request from a server
would usually be for a simple HTML file, which cannot easily be pipelined,
and authentication would take place at that point.

One could improve bandwidth usage somewhat by defining a GETLIST
method to replace a series of GET requests.  This probably isn't
a big win, though.

-Jeff

Received on Friday, 22 September 1995 13:41:09 UTC