The Artima Developer Community
Sponsored Link

The Desktop as a Grid Service
Test-Driving Sun's Prototype Display Grid
by Frank Sommers
February 8, 2006

<<  Page 3 of 5  >>


Cache Your Pixels

A different approach to distributing a desktop's services on the network starts not with a client-server architecture, but with the well-known technique of data caching used to speed up access to networked information. In many enterprise applications, for instance, clients often maintain a local cache of frequently accessed data in order to avoid the overhead of performing queries each time similar data is requested.

In a graphical desktop, the raster image data rendered by the operating system and graphics chipset is buffered to the video memory, or frame buffer. Instead of sending that data to the display, the buffered raster data can be distributed on the network in a replicated cache, with a master copy on a server, and a secondary copy on a thin client. Updates made to the screen are first copied into the server's cache, and then are immediately replicated to the thin client's cache. That architecture almost completely pushes desktop computation to the network, and leaves to a user's system only the task of keeping the local buffer cache in sync with the server's buffer.

The problem of keeping the distributed pixel caches in sync between the desktop client and a server is orthogonal to the type of windowing system used, and even to the operating system. Such a mechanism can be implemented on any operating system or windowing system by means of a virtual graphics device that, instead of pushing a bitmap raster to the display, pushes those rendered images into the server-side of the distributed cache, which then takes care of synchronizing local and remote cache content.

Successful cache replication depends on a high hit-to-miss ratio: The less the screen changes, the less data needs to transfer from server to thin client. That fits the pattern of most desktop usage well: in a typical desktop session, most desktop UI changes occur in response to user actions. And user actions are relatively sparse.

Typing text in a word processor, for instance, causes very few changes on the screen - mostly just in the screen area of the newly typed text. The rest of the screen pixels remain the same, requiring relatively small amounts of data to update the thin-client's screen buffer. The worst-case scenario is a full-screen movie. A typical uncompressed MPEG 1-encoded movie with 25 frames per second, in 24-bit color and with a display resolution of 1280x1024 pixels, would require a sustained bandwidth of approximately 750 Mb/s. Compression would reduce that bandwidth requirement. In between these extremes are user actions such as dragging a window or scrolling inside windows.

Even with many screen changes, the server's cache update mechanism can intelligently compute the difference between two consecutive screen updates. For instance, some white pixels may stay fixed between two screen updates even when scrolling text in a window. The server can compute such differences via a bit-by-bit comparison of two rasters, and send only the minimal updates necessary to the client.

Screen updates may be communicated between client and server via a protocol that aims to minimize the amount of data transmitted. Instead of sending arrays of pixels representing screen changes, drawing primitives can affect bulk updates in the client. For instance, if two screen areas contain the same set of pixels, a COPY command can instruct the client to copy one rectangular screen area to another screen location. Or, if a screen area consists of similar pixels, a FILL command could cause the client to fill that area with the specified pixel.

Such protocol primitives allow protocol optimizations specific to thin client and server communication, and are independent of the original display protocol, such as X. They also facilitate graceful degradation of display quality in the face of communication obstacles, such as high packet loss ratio. The server, noticing the dropped packets, could re-transmit only the updates most essential to maintaining usability. As well, communication between client and server can be compressed to further reduce bandwidth requirements. That leads to a design depicted in Figure 5:

Figure 5. Distributed pixel caching in a thin-client architecture.

The communication protocol between a thin client and the server determines not just the amount of required bandwidth, but also the division of computational responsibilities between thin client and server. For instance, one objective of the protocol's design might be to minimize the computation cost of executing the protocol on the client, allowing for clients with low-cost CPUs, low power consumption, and relatively small amounts of memory.

At the same time, placing the bulk of the computational burden on the server allows a service provider to take advantage of the scalability characteristics inherent in the replicated buffer-based thin client design. In addition to distributing on a grid the various services that provide a desktop session's functionality, a service provider can push the thin-client and server protocol processing to a grid as well.

That could take advantage of the parallelism inherent in processing screen updates: Parts of the screen can be handled by independent "compute servers," each server computing a portion of screen updates. Results of those computations can be provided as input to a protocol processor that computes the drawing primitives representing screen changes. Finally, compression can be performed in parallel as well. While communication cost between grid nodes may well dominate such an operation, this example illustrates the scaling potential of the architecture. In essence, this architecture turns the problem of desktop management into a problem of high-performance, high-throughput computing.

This model of thin client computing also provides session mobility: Since all desktop state resides on the server, a user can disconnect from a thin client at any time without having to close the desktop session. Later, the user can log in from another thin client device, and resume the desktop session from the exact state she left it earlier. As in the case of X Windows, a replicated cache-based thin client desktop can be implemented in hardware or software.

Figure 6: Session mobility by redirection

<<  Page 3 of 5  >>

Sponsored Links

Copyright © 1996-2018 Artima, Inc. All Rights Reserved. - Privacy Policy - Terms of Use