How best to exploit this backend computing resource varies with the performance and reliability of the wireless link. Nevertheless, we believe that shared computing power can enable very powerful mobile services. For example, the Berkeley InfoPad exploits pooled computing power to permit a small number of workstations to support a large number of end users. And unlike a distributed system cobbled together from laptops, it is much easier to share processing and memory resources on behalf of many users in a NOW.
For cases where the network performance is poor, we will use the network servers to execute agents on behalf of the mobile units, and to perform application- and data-specific compression before transmission over the wireless link. Agents mitigate poor latency by reducing the number of link crossings, while compression increases the link's effective bandwidth. Both of these strategies can require substantial cycles from the network servers.
The architecture relies on strongly typed transmissions. A dynamically extendable type system enables type-specific compression levels and abstraction mechanisms for progressive object transmission, thus husbanding link bandwidth. For example, depending on link quality, we send a raw, compressed, or lossy/highly compressed bitmap to a mobile client. As an extreme example, we can perform edge detection and OCR on the bitmap of a topographic map, only transmitting the text and edges. This distillation process produces a summary version that can be used to evaluate the value of the full bitmap; in the case of the topographic map, the distilled version is usually sufficient for making decisions. These techniques exploit the backbone compute servers to trade software latency to compress for increased effective bandwidth, thus reducing overall latency. The compressed forms can also be cached to further increase their benefit.
The development kit will be based on Tcl/Tk. We will extend it to support (1) strongly typed connections with data-specific compression/abstraction, (2) continuous media, and (3) Internet, FAX, WWW and SGML access. We will develop a range of bandwidth/computation trade-offs for each data type, distinguishing between versions, which are independent, from layers, which are part of one version and form a sequence of increasing detail useful for progressive transmission of objects. For example, a PostScript object has at least two versions: ASCII text and full PostScript description. Images in the document, such as a map, use a corresponding type known to the application support subsystem. A map data type could exploit layering for progressive transmission, first sending the major roads and landmarks, and adding layers of increasing detail with each subsequent transmission (see figure). Layers/versions can have meaningful names; an application can ask for specific layers, such as a map's "elevation lines" or "county boundaries."
We will also develop cost models based on link instrumentation and statistical model fitting. These techniques, first developed for mapping parallel programs onto a variety of platforms [Brewer 94], can accurately predict the overall latency for each transmission option for a given data type. The models will include the link latency and the compression/decompression time, and will exploit knowledge of the cache contents. We can decide the optimal format by simply evaluating the models for each level and picking the one with the lowest predicted latency. The models typically pick the first version to transmit; subsequent versions are controlled by the user. We will also experiment with predictive models to minimize access charges, by selecting the cheapest network and data representation.
The application architecture will also provide for prefetching (speculative downloads) and client-side caching. Prefetching reduces latency in exchange for bandwidth, which is especially useful for asymmetric communications like satellite downlinks. Client caching is advantageous for high-latency or low-bandwidth links avoiding round trips at the expense of more client memory. In fact, the user code on the mobile device will be cached using these mechanisms, so that the clients can dynamically download missing decompression or decryption functions as needed.
We can reduce required bandwidth and round trips by allowing applications to move computation across the wireless link via agent programs. An agent is just an instance of a small application, so it has access to the same strongly typed connections as any other, and can use the same mechanisms to adjust its behavior depending on dynamic link quality. In fact, user code is just another transmission type and can be sent in either direction. A key issue is the ability to download untrusted code safely. We will employ two approaches to code transmission. First, we will support scripts written in Safe-Tcl, a subset of tcl that is safe because it has very limited OS and file-system access. Safe-Tcl is good for simple agents written by the end user.
Consider building an application that combines information from multiple heterogeneous databases, using a full-text web indexer and on-line library card catalog. Typically the end user must do the combining. Alternatively, an agent running on the representative can access, combine, and filter the requested information. The agent uses the card catalog to find relevant documents and the web-indexer to determine which are on line. The end user then receives an annotated reference list with hypertext links for the documents. The wireless link is only traversed to start the search and receive this list; alternatively the results could returned along an alternative path such as e-mail or FAX. The agent could prefetch abstracts or whole documents should the end user decide to view an on-line document. Other examples include combining maps and intelligence reports from multiple sources, and combining patient information with medical databases.
The second approach for code transmission involves dynamically translating and linking agent code written in a canonical assembly language. We will use tokenized MIPS assembly as our download format, since it is easy to generate quality code from C/C++ using gcc as a cross compiler. Given code in this format, we then perform two transformations (in one pass). First, we convert the code to native assembly for the mobile device; this is manageable in part because of the simplicity of MIPS assembly. Second, we use software fault isolation to add native instructions that prevent the code from reading or writing outside of its assigned memory regions, or from executing unauthorized OS/library procedures. Thus untrusted code can affect only a predetermined range of memory and set of procedures. The transformation can occur on the proxy if the downlink is trusted (possibly through public-key authentication).
This approach enables arbitrarily sophisticated agents, since we can write efficient agents in C/C++ or other languages. This is crucial for adding new decompression/decryption modules dynamically, since such modules tend to be CPU intensive. For example, it would not be practical to write an MPEG decoder in safe-tcl. There is a second more subtle advantage, which is that only the protocol skeleton needs to be permanently installed on the mobile device. Thus, sensitive code such as custom decryption software can be downloaded as needed, which implies that lost or stolen mobile devices need not contain any proprietary or classified information.
Finally, the proxy architecture allows uniform handling of disconnection, since it maintains state across sessions. The network management layer will notify the application support services layer of a disconnection, whether intentional or not. This allows the services layer to store results until the user reconnects without any help from the application. This is particularly useful if a connection is expensive or unreliable, since the user can start an agent (on the proxy) and reconnect later to get the results. This also gives us more freedom in implementing fast handoffs; if we temporarily lose the connection during a handoff, there are no adverse effects and applications will in fact not even know (unless they asked to be notified).