Re: Efficiency of FTP URLs
Gary Adams - Sun Microsystems Labs BOS (Gary.Adams@east.sun.com)
Mon, 25 Jul 1994 14:01:09 +0500
> From: Rick Troth <troth@rice.edu>
>
> > ... I got to thinking that this would be
> > an obvious place for an optimization: leave the FTP open until done parsing
> > the HTML document in case any inlined images (or whatever) might be needed.
> > This morning I confirmed that MacWeb 1.0a2, MacMosaic 2.0a2, XMosaic
> > 2.4, and WinMosaic 2.0a2 take the inefficient approach of a separate ftp
> > connection for each inlined image. It would seem that optimizing this would
> > help the load on ftp servers, and response time to the user.
>
> And Dan suggested that we rewrite TCP for similar reasons.
>
> Yeah ... it's overhead. I say, leave it in there for the
> sake of compatibility. Let each transaction be a separate TCP (FTP)
> connection for the sake of uniformity. I'm not advocating waste,
> but bandwidth is getting cheaper, CPU cycles are getting cheaper,
> and storage is getting cheaper. The economics are against some
> kinds of optimizations.
>
> Now ... if the library had some "trick" whereby it could
> leave that FTP control socket open across URLs, fine. There'd have to
> be some kind of time-out so that if the control socket remained unused
> it would close automatically. But I strongly suspect that this all
> serve to hinder the portability of the library code. Then too,
> everyone should bear in mind that not all WWW clients and servers
> are using the same library nor even any of its derivatives.
>
We've been experimenting with a modified server and client that deal with
a header like this :
Pragma: keep-connection
This allows both parties to take full advantage of Content-Length headers
and to gracefully recover from closed connections or variable length
timeouts based on current load considerations. For same site transactions,
which are pretty typical, there are significant performance gains
available within the current protocol framework.