Under one set of theories, the user agent requests pages it feels are
likely before the user actually "clicks" on the pages (the "fish
search" work described at WWW3 being one example of how this would
work). This allows the user to set preferences about what sorts of
pages are likely to be wanted and works for pages with links to
multiple sites; it may, however, lead to piggish behavior in which a
user/user agent request lots of things they don't use, thus
overloading the servers.
Under another set of theories, the server manager decides which of the
pages it serves are related, and "pushes" related pages when one of
the related set is requested. This prevents the piggish behavior by
leaving some control in the hands of the server manager; it works for
pages only on a single server, but it may work better for such pages
because the designers understand which ones are related.
Brian's suggestion seems to be a modification of the server push
solution, designed to deal with the need he sees for server managers
to have reasonable numbers for pages seen. In it, the server pushes
related pages, but not whole pages--specific byte ranges, so that the
user agent must request the rest of the document, thus giving a
trigger event for Brian's statistics. The disadvantage to this is
that this forces a new tcp connection and a second round trip, even
for pages which might normally not reqire one, and it inherits the
problem of not working for pages with links to multiple servers.
Given the need for a new round trip and the need to merge the
pre-fetched parts with the rest of their ranges, I really wonder how
much of an advantage this version of server-push will be for the basic
point: improving apparent speed for page loading. I also really
wonder how easy it will be to handle caching with this system (pushing
related pages onto a cache seems like a win to me, but pushing partial
pages onto a cache seems like a lose). Knowing that Brian has a lot
of experience in these matters, however, makes me suspect that I am
missing the point, and I hope someone can enlighten me.
Ted Hardie
NASA Science Internet
Brian Behlendorf <brian@organic.com> writes:
> Hmm, after a little thought, it seems like an even smoother solution would be
> to leave pre-fetching up to the server completely. I.e., if someone requests
> a page from my server, I return to them not only that page but the first n
> bytes (or all) of each subpage in a multipart message. That leaves it up to
> me, the page designer/server administrator, to decide exactly what parts of
> my site can be optimized in such a way, and it lets me tune the prefetching
> algorithms to my liking.
>
> It may be both a protocol and UI challenge to model the act of a server
> "throwing" unrequested content at a client... perhaps left for HTTP-NG?
>
> Brian
>
> --=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=--
> brian@organic.com brian@hyperreal.com http://www.[hyperreal,organic].com/
>
>