At 14:01 01-10-98 -0500, Noone Special wrote:
>2) Browser type/configuation
>   Most browsers can be configured to attempt 
>   more than one retrieval at a time.  If there are
>   10 images to download, it will send requests for
>   all 10 of them (all in separate socket 
>   connections)  The more connections from the
>   browser, the faster the overall download
>   tends to be (because of reason #3)

What browsers actually operate as you describe (specific versions and
platforms), and why?

Current browsers use HTTP 1.1 when they can, and as best I've been able to
observe, operate accordingly. The older browsers I've seen typically
defaulted to the very reasonable number of up to four concurrent sockets.

W. Richard Stevens in "TCP/IP Illustrated Volume 3 (Addison-Wessley)
presents experimental data which demonstrates (convincingly at least to me)
that four is a very good choice, and that in fact values larger than four
(as I'd expect at some point) actually result in considerably poorer
performance.

I'd be very curious of the evidence you have to support your assertion, and
to contrast it with that by Stevens.

>3) Connection speed/reliability
>   There is almost always at least some dead 
>   space in a connection.  

Almost always? Except in cases of server overload, or network congestion,
once the data stream is underway, then possibly ~occasionally~ but hardly
~almost always~. And, in the cases where such occurs, initiating additional
connections would seem unlikely to improve the situation.

The issue with HTTP 1.0 is that each file references involves a socket open
and file request, with a latency of at least one RTT (round trip time). By
having a small number of concurrent socket connections, one manages to
overlap such latency with other data transfers, without actually delaying
other data transfers.

With HTTP 1.1, this really shouldn't be an issue, since dealing with this
issue was one of its design goals, and one which seems to have been quite
successful.

/Harold

-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Harold A. Driscoll                       mailto:harold(at)driscoll.chi.il.us
#include <std/disclaimer>      http://homepage.interaccess.com/~driscoll/

HWG: hwg-graphics mailing list archives, maintained by Webmasters @ IWA