In article <9409121903.AA21560@dxmint.cern.ch>, David Kristol writes:
> There has been some discussion here about keeping connections open
> between client and server after a transaction is complete. I don't
> recall seeing a resolution, however, so I want to put forth what I
> think is a simple solution, and I don't recall seeing anything
> comparable proposed.
I think similar solutions have been discussed, although early enough on in the
Webs history that they might not show up on www-talk archives.
Briefly, keeping the connection open requires the server to commit resources
until timeout or explicit quit, reducing the number of connections that can be
made at one time and reducing the throughput. On the other hand, making lots of
connections to get tiny files incurrs significant overhead in establishing
connections.
> [about gopher vs ftp] The only significant difference is that ftp holds open
> the connection
> and thus consumes server resources while the client user browses the
> archives. This turns out to be costly.
Exactly.
> An alternate proposal that would gain most of the network benefits
> would be an MGET method in HTTP. This would require two connections
> to download a document containing, say 20 images which is not as
> good as 1, I know, but it would reduce load on the server rather
> than increase it.
> Another proposal which has been discussed is to use MIME multi-part
> document format to make an HTML document with 20 images into a
> single document.
These have been proposed before, certainly by me, and I got the impression even
then that this was not considered novel ;-). I suggested that a client that had
retrieved a document containing 20 images all from the same site should send a
list of the images it wanted [ problems with specifying such a list] and get
them back in a MIME multipart. The server would need to specify in its accept
headers that it could handle multipart [problems with some existing clients
sending */* in the accept header] and the client would unpack all the images.
Advantage is that text only clients or clients with inline images turned off for
selective retrieval do not have to get all the images then throw them away, as
they would with a single multipart containing text plus images in John's
suggestion.
Problems were many:
1) Either the server has these multiparts all made up, in addition to the
individual files for non-multipart-capable clients [extra storage, extra set-up
complexity when establishing a server] or makes them on the fly when asked [
extra processing load on servers] possiblky cacheing them [but see below]
2) The client may have _some_ of these images already in its cache. So the multi
get request would be different each time from each client, requesting a subset
of the images in the document. This tends to rule out pre-generated multiparts
on the server.
3) There may be (a chain of) cacheing proxies between client and server. Suppose
our 20 image document has been retrieved. The client already has images 1, 3 and
5 so sends a multiget for the rest. The first proxy has images 2, 7 and 12, plus
14 except that just expired so the proxy would have to do a conditional GET on
14 to get the most up to date version if it has changed. The proxy must parse
the multiget list from the client, edit the request for 2 7 and 12, forward on a
request for the others.
So the client gets:
1, 3, 5 from its internal cache
4, 6, 8..11, 13, 15..20 from the server via the proxy, as a multipart
2, 7, 12, 14 from the proxy, perhaps as a multipart [extra proxy processing]
And the server receives a conditional get from the proxy for 14, which incurrs
an additional connection delay and may result in 14 being sent singly from
server to proxy.
Add a couple more proxies in the chain and it seems like it isnt such a big win
anymore, and is rapidly getting complex.
> The problem with this is that it represents
> substantial effort on the part of browser and server writers and
> is, for that reason, not likely to get implemented.
Indeed, unless the wins are great enough.
An alternative approach is to reduce the slow start connection time, use a
different protocol than HTTP, etc. I believe this is discussed on www-speed
[corrections if I am wrong please]
-- Chris Lilley +--------------------------------------------------------------------------+ |Technical Author, ITTI Computer Graphics & Visualisation Training Project | +--------------------------------------------------------------------------+ | Computer Graphics Unit, | Internet: C.C.Lilley@mcc.ac.uk | | Manchester Computing Centre, | Janet: C.C.Lilley@uk.ac.mcc | | Oxford Road, | Voice: +44 61 275 6045 | | Manchester, UK. M13 9PL | Fax: +44 61 275 6040 | | X400: /I=c/S=lilley/O=manchester-computing-centre/PRMD=UK.AC/ADMD= /C=GB/| | <A HREF="http://info.mcc.ac.uk/CGU/staff/lilley/lilley.html">my page</A> | +--------------------------------------------------------------------------+