Location of Web++ client

The conversion from a logical URL into a physical URL can be done at several points on the path between a client and a server:

• Server or server-side proxy
• Client-side proxy
• Browser

A single server has only incomplete information about the network topology and cannot easily predict the kind of end-to-end performance a client would receive from other servers. Similarly, it is difficult for a server to predict whether the client would be able to reach any of the remaining servers. Therefore, the binding of logical URL to a physical URL should be done close to the client. This can be achieved by embedding the binding algorithm in a client-side proxy [4]. We see, however, several problems with the proxy approach. First, it requires making some changes to the existing proxies. Second, the proxy approach is a one-size-fits-all solution. For the same proxy, it is difficult for different content providers to use different algorithms for server selection. Third, the client-side proxy is inflexible for upgrades since it requires large numbers of users to install new versions or patches. Finally, adding a proxy on the path between a browser and a server leads to performance degradation. To quantify the performance degradation, we re-executed the client trace collected in a public lab at Northwestern University in a period of three days [35] and sent each request either directly to the Internet or via an Apache 1.2.6 proxy. To quantify only the proxy-access overhead, the proxy did no caching. The results in Figure 2 show that a commodity proxy may increase the response time by as much as 28% (223.2 ms). Similar results were obtained in [28]. We conjecture that the performance degradation is partly due to the store-and-forward implementation of Apache, i.e., the first byte of the response is not forwarded to the browser until the last byte of the body has been received by the proxy.

  

Figure 2: Proxy access overhead.

Ideally, the client (or a client-size proxy) should dynamically download the code that performs the binding. The code can be downloaded together with the data. Such a solution does not require the end-user to install any software or to upgrade the browser. Different data providers may use different algorithms to perform the binding. Finally, upgrades can be quickly distributed among a majority of users. We are aware of two technologies satisfying the above criteria: Java applets and ActiveX controls. Since Java applets are supported by both Netscape Navigator and Microsoft Explorer browsers, we opted for an applet based implementation of Web++ client.

We also measured the overhead of executing an applet within a browser. Both Microsoft Internet Explorer 4.x and Netscape Navigator 4.x incur a relatively high overhead (3 s) to initialize the Java Virtual Machine. However, such initialization is done only once per browser session and could be done asynchronously (unfortunately, both browsers do the initialization synchronously upon parsing the first reference to an applet). We found that the execution of an applet method that implements the binding of a logical URL to a physical URL took on average 15 ms on Netscape Navigator 4.002 and 26 ms on Microsoft Internet Explorer 4.0². In both cases the extra overhead is an order of magnitude smaller than the overhead incurred by using an Apache proxy and less than 4% of the average response time measured in the trace.

We observe that the Web++ applet does not have to be downloaded with every resource. In particular, the applet can be cached by the browser as any other resource. The default browser behavior is that the applet's timestamp is compared to that on the source server (using HTTP conditional GET) only once during each browser session.