Disagree: Multiple connections

Hi

Let's see if this poor-man WIT works ;-)

> > When this is working then clients have a far more powerful tool to keep
> > connection alive, not only for inlined images but also for HTTP
> > sessions, video etc.
> 
> It should be noted that one company's solution to the problem of 
> time when loading html pages with lots of inlined images was to 
> 
> 1) grab the page 
> 2) note the images needed for download
> 3) open up separate TCP connections for *each* image
> 4) find out the width and height of each image as it's coming down the 
> pipe, laying out a box in which the image gets filled in as it arrives - 
> thus allowing the page to be layed out perfectly before all images are 
> received.
> 
> We here would think that 1 x N is the same as N x 1, so opening 4 
> connections for 4 different things shouldn't be faster than one 
> connection containing all elements, but aesthetically it is *much* more 
> appealing.  

I see three reasons for not using the proposal above:

1) TCP has a slow start in all connections as it has no apriori
knowledge about the round trip time for the connection and hence must
use a long timeout for acknowlegements. As more and more data travels
over the connection the variance of the estimated round trip gets
smaller and the connection gets faster.

2) A connection establishment using TCP requires a 3-way handshake
which for small transactions actually can be the major time consuming
task.

3) When TCP closes a connection at least one of the parties is put into
a TIME_WAIT state where the socket can't accept any new connections.
With a relatively small amount of new connections this causes no
problems but if the amount of sockets hanging in TIME_WAIT state
explodes then this can be a real problem. We already have this problem
on our `info.cern.ch' server which simply runs out of sockets.

Maybe the remarks say more about TCP than about the method you mention
above ;-) What is needed is basically a transaction oriented protocol.

> Could we get that same effect with one connection?  Sure - the browser 
> must be (simulated if not OS_supported) multithreaded, so it can be 
> accepting data and rendering simultaneously, and when accessing inlined 
> images a HEAD command should be sent for each image whose response shows 
> how much screen acreage it'll take (which I *think* can be determined 
> in the first couple of bytes of any GIF or JPEG).

The implementation is based on that every thread has its own socket.
Otherwise it gets very difficult to sort the incoming packets into the
set of threads talking over the same connection.


-- cheers --

Henrik Frystyk

Received on Saturday, 8 October 1994 11:56:22 UTC