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: Fri, 22 Sep 95 14:40:09 PDT
Message-Id: <9509230032.AA04483@netmail2.microsoft.com>
To: mogul@pa.dec.com
Cc: http-wg%cuckoo.hpl.hp.com@hplb.hpl.hp.com

] From: Jeffrey Mogul  <mogul@pa.dec.com>
] To: Paul Leach
] Subject: Re: Persistent connections: aborting requests in progress.
] Date: Friday, September 22, 1995 1:27PM
]     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 can skip step b) if one can tell in advance that it won't be 
required, or that failure to wait when one should have can be recovered 
from safely.  I take your "presumably" to mean that most of the time 
everything falls out because initial requests aren't typically 
pipelinable -- but I wouldn't want to depend on being able to omit step 
b) in all cases.  (As far as I can see, it is allowed for in-line GIFs 
(or anything, for that matter) to request authentication, for example; 
and there have been proposals to do content negotiation via additional 
message exchanges -- maybe you negotiate between GIF and video forms of 
an inline image, for example.)

So, in order to make things robust, we'd either need to document some 
restrictions that make skipping b) always safe, or know in advance when 
it is safe to skip and handle the unsafe cases by waiting to complete 
the negotiation, or figuring out how to recover if the server gets a 
GET in response to a request to negotiate something -- maybe just 
draining the pipe until the client's request-aheads are all gone and 
the correct response to the negotiation arrives would work, and perform 
well if it doesn't happen very often.

(Non of the above should be construed to say that what Venkat 
implmented  wasn't exactly the right thing to do to as en experiment to 
evaluate how big a performance win pipelining might be...)

Received on Friday, 22 September 1995 16:34:56 UTC

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