On Jun 5, 2:22am, Scott Hess (possibly) wrote:
> On 4 Jun 1999, "Allen Smith" wrote:
> >On Jun 2, 7:18am, Reuben Farrelly (possibly) wrote:
> >> I guess one of the more important points to note is that for many if
> >> not most people, Squid is used primarily to *save* bandwidth and
> >> therefore cost.
> <snip>
> >Certainly. That's one of the points behind the below idea - the client
> >is almost certainly going to make the request anyway.
> >
> >> At Wednesday 2/06/99 04:32 AM -0400, Allen Smith wrote:
> >> >A minor version of this that wouldn't be nearly as hard to implement
> >> >(I've looked at doing it myself, although it's currently pretty far
> >> >down on my ever-growing list of tasks) would be requesting and caching
> >> >any cachable referred object (referred via HTTP responses, not HTML
> >> >coding).
>
> I'm not sure I follow. Prefetching should use strictly as much or more
> bandwidth, never saving bandwidth. At the limit, if all clients request
> all such objects, the bandwidth usage will be identical. But if any
> clients don't request all objects, bandwidth will potentially have been
> wasted. As far as bandwidth usage goes, it would seem to be a losing
> proposition.
I'd expect that the bandwith usage would be identical, unless people
are stopping the browser before it follows the referral. In other
words, minimal bandwidth usage with this speedup. I realize that for
some people, minimizing bandwidth usage is such a priority that
anything that compromises it is a bad idea; thus, I'd make this an
option. However, I suspect it would not be significantly affecting of
bandwidth for most cases.
-Allen
-- Allen Smith easmith@beatrice.rutgers.eduReceived on Sat Jun 05 1999 - 00:10:31 MDT
This archive was generated by hypermail pre-2.1.9 : Tue Dec 09 2003 - 16:46:44 MST