On Thu, 07 Aug 1997 18:47:46 EDT, "Farley, Tim" wrote:
>>> The problem is that the client asks for a page, then has to receive
>>> it before it can be parsed and subsequent requests pipelined.
>
>Perhaps I wasn't clear.
>
>The client doesn't have to *completely* receive an HTML page to pipeline
>subsequent requests. It is certainly feasible to build a browser which
>parses the HTML as it is being read from TCP, and posts the subsequent
>requests for inline graphics to the host at the earliest possible
>moment. I.e. go ahead and post the GET's for the icons before you've
>even hit the </HTML> tag of the initial GET. It might require a
>multi-threaded design, but it could be done.
My understanding was that certainly widely used browsers (at least
Netscape) are multithreaded and do initiate image requests before the
entire html text has been received.
Also, since tcp idle time is defined as a RTO and not a RTT, even a
client who must get the entire html page before requesting icons has a
chance to get the request out in time. (Beware, there's a bug in the
text of Steven's book on the definition of idle time.)
Therefore I don't believe that slow-start restart will be a problem
for HTTP/1.1 requests of a single web page (html and embedded images).
Odds are reasonable that all will happen with the fullly developed.
BUT many people would like persistent connections to help out the
``next click''. (After reading one page, the reader clicks on a link
to another page on the same server. Does this page use the persistent
connection? If it does, does the server slow-start again?)
If the server does slow-start restart after one RTO and people have a
reading time larger than an RTO, then the second click will always
restart with a new slow-start.
-John Heidemann
This archive was generated by hypermail 2b29 : Mon Feb 14 2000 - 16:14:29 EST