While current Internet is looking for standards that it can be based and grown upon them in a stable manner, different protocols have been suggested by several consortiums and groups. The Internet of the future will likely contain not only the standard PCs and portable computers but many other devices as well. We have already seen the mobile phones that are trying to access the world of Internet despite their limited capabilities in power and size.
In order for such mobile devices to access the Internet
a new protocol must be used. The weaknesses mentioned,
about the low power and limited size that such devices may have forced us to
treat them in a different way depending on their capabilities.
This can be explained by the following example.
When a PC (a client) is
requesting a web server for a web document the web server will return that document.
When another device with some different capabilities (mobile) is requesting
the same document as in the previous case the interaction between the client
and the server should not be the same.
Suppose that the web document contains large images. In the first
case, the computer has a screen capable of presenting such images. In the
latter case however, the mobile phone has a much smaller screen incapable
of handling those large images. Such devices need to be integrated with the
current Internet in a way that they receive the best result depending on their
capabilities. For that reason, we need a protocol that will take care
of the interaction between clients and servers and make servers
'recognize' the kind and the capabilities of the client of each incoming
request.
Such protocol, that could provide the web servers with the information of what kind of client performs a request each time, is the new CC/PP (Composite Capabilities/Preferences Profiles) protocol. This protocol is suggested as a standard from the W3C group [WWW] ( http://www.w3c.org ).
There is also another application developed in Monash University that can serve a mobile device with content read from a file [LT]. The system takes as input a document in MS excel format. It then applies some constraints, that specify the layout of the output document. Depending on the CC/PP attributes read from .ccpp file it produces a file that can be shown in a PalmOS emulator. The format of the file containing the CC/PP attributes is conformant to the W3C suggestions about the format of the Profile header. In this approach the CC/PP information is not sent by the client using a known protocol like HTTP. HTTP protocol may be involved in a newer version.
Four different approaches can be used in order to provide CC/PP functionality
to a client:
1. The first approach is implemented with two intermediary proxies, a client proxy
and server proxy. In this architecture CC/PP information is only transferred between
these two proxies and they are responsible to perform the protocol translation in
order the end-to-end (client through server) communication to be achieved (Figure 1).
Having these two proxies between the corresponding client and the server may make
the communication slow. There is also the issue that adding more intervening parts
in the system is like adding more failure points to the round-trip request-response
scenario and becomes less flexible in possible future changes.
2. The second approach adopted from the Keio University includes one intermediary proxy, a server proxy. The PANDA browser implemented is CC/PP aware, so the client proxy for the translation between HTTP to HTTP+CC/PP and vice versa is not needed (Figure 2). In this approach the new browser implemented helped the researchers to test the functionality of the CC/PP protocol. Having only one proxy is a common case as this architecture is widely used in current Internet. The difference is that proxy's current usage is focused on serving clients with the cached documents so they are placed closer to the clients and away from the server in order to minimize the transfer delay of the documents. Locating a proxy away from the client may not have the same effects.
3. The third approach is to implement a CC/PP aware web server communicating with an intermediary client proxy, as seen in Figure 3. That means, that a web server must be capable of handling HTTP with CC/PP headers. The client proxy is used to translate the HTTP requests of each client to new HTTP requests including CC/PP information.
4. At last, there is the ideal approach of both server and client capable of sending and receiving CC/PP headers. Though is the best approach it is better to make one stable step each time and pass through some of the mentioned approaches (Figure 5).
A client proxy as shown in the figures 1 and 3 communicates with the web client with the standard HTTP protocol. The functionality of the client proxy is to convert the standard HTTP headers sent by the web client to extended HTTP headers that contain CC/PP headers (HTTP headers + CC/PP headers). The new headers are then sent to the appropriate web server. If the web server is CC/PP aware then the headers are sent directly to that server. Otherwise the headers will be sent to a server proxy to make the appropriate translation.
A server proxy is used in implementations where the web server has not been transformed to support the CC/PP protocol. Its functionality is to:
Our approach is based on the usage of a client proxy and is focused on integrating the server's proxy functionality inside a web server as a module. The whole system includes a client proxy, a web client (e.g iexplorer netscape) and the transformed server with the new module (Figure 6).
A well-known web server that is open source and is widely used is the Apache web server. These features made our choice easier between other existing web servers. The API (Application Programming Interface) provided from the Apache web server enables the implementation of new modules. We chose not to consider the issue of the client part as we wanted to focus on the server-side. Instead of trying to extend a well-known client with the CC/PP protocol, we decided to use a simple client proxy that could do the appropriate work of the transformation between original HTTP and extended HTTP (CC/PP headers included).
Till now we have implemented a module for the Apache server that handles the CC/PP headers. This module is called mod_ccpp (mod_ccpp.c). It can be imported to the Apache like all the other extra modules with the usage of '--activate-module' derivative. This can be done in the initial configuration of the server. In order to test our module we have linked it with the ImageMagick (an image processing tool) library which can be used to transform images. ImageMagick library provides an API to transform images between formats and sizes. The generated web page is now dependant on the client's device characteristics sent in the CC/PP header.
Including that library inside the module makes the deployment of the module little more complicated. One automatic generated Makefile had to be altered in order to link the module with the ImageMagick library. Having installed the module, we were able to make requests to the Apache with various values for the CC/PP header fields. The server responded as expected in all cases.
As future work we may try to develop a client patch that could enable a browser (Mozilla) to sent CC/PP headers and avoid the usage of the client proxy. Some measurements will be also held to determine the overhead of the CC/PP headers processing and the image transformation.