I was too vague. While I proposed having the server keep open the
connection, I did not mean for that to be indefinite, or even long.
Pick a satisfactory round-trip delay, increase it to account for
client-side processing, and use that as the length of time for the
server to retain the connection. That should reduce the risk of
exorbitantly wasted network resources.
Note that the TCP close/wait period takes on the order of minutes. If
images could be transferred over an already open connection, there
would be fewer connections in close/wait state, and a net saving of
network resources.
> 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. It would also be vey easy to implement
> in servers and browsers.
I agree this accomplishes much the same thing. However, the transition
is messier, because MGET-capable and non-MGET-capable components don't
interoperate very well. With my proposal, older versions of softer can
operate successfully with new.
>
> 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. 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.
Right. It's also a bit harder for the person creating WWW pages
(assuming it's done by hand, which it frequently is).
Dave Kristol