stating the obvious archives | about

TranSending the Client
Jul 28, 1997 :: Michael Sippey

It's no secret that bandwidth hasn't even come close to keeping pace with the rapid evolution in computing power. Over the past five years processing cycles have become cheaper and more widely available, while connectivity beyond 28.8k remains out of reach of most non-corporate Internet users. Daily use of the web over a POTS dialup line only highlights the vast gulf that exists between the power of a Pentium Pro processor and the measly transfer rate of a Sportster modem.

Meanwhile, the browser companies, eager to win control of our desktops, try to distract us from the slow surfing experience by chewing up processor cycles with collaboration tools, push solutions and client-side scripting. As the recommended hardware platforms for Netscape's and Microsoft's browsers escalate into the stratosphere, the notion that these bloatware products could be considered "thin clients" is laughable. IE 4.0 requires more RAM than Excel.

A team of computer scientists at UC Berkeley, however, is out to change the fundamental way we think about using the Internet, with a simple slogan that turns the browser war on its ear. "Trade cycles for bandwidth."

The Global Mobile Computing by Proxy project (or GloMop, for short) is building products and services that take advantage of processing cycles where they are the cheapest -- on readily available desktop workstations. These workstations act as a proxy for a thinner client on the other end of an Internet connection, and a "thinner client" can range from a PC surfing over a slow modem all the way down to a handheld device. The proxy can fetch documents and transcode them in a way that improves the surfing experience of the end user.

In essence, the browser software (which may reside on hardware with a slow connection or limited processing power) can be extended out into the network, where economies of scale mean bandwidth and cycles are cheaper.

Confused yet? Here's an example of how proxy computing can change the way you surf the web.

The latest application from the GloMop group is TranSend, a freely available proxy service that reduces image size on the fly while surfing the web. By distilling GIFs and JPEGs on the web, TranSend dramatically improves throughput for web users surfing through dialup accounts. Using TranSend is easy: you only need to enter the service's URL in the proxies section of Netscape or Internet Explorer, and voila -- instant image distillation, and faster surfing. According to the group's research, users of TranSend can "speed up Web browsing by a factor of 3 to 7."

While the end-user interface is nearly transparent, the server side of the TranSend service uses a group of clustered servers to manage multiple network caches, the image distillers, and a user profile database to store your image size / surfing speed preferences. The cluster architecture enables the service to scale gracefully: the service is currently running on a group of 15 Sun SPARC Ultra-1 workstations, and has been implemented for the 25,000 users of UC Berkeley's home-IP dialup Internet service. Clustering eliminates the "forklift upgrade," since adding more users means only adding more off-the-shelf workstations into the cluster. (It's this cluster technology that's behind Berkeley-born Inktomi Corp. and their HotBot search engine.)

While reducing image size might not be at the top of any one surfer's wish list, the beauty of the TranSend/cluster architecture is that it's easy to deploy additional applications on top of the existing system. In a research paper titled "Extensible Cluster-based Scalable Network Services," the GloMop team explains that "new services can use [the Cluster-based] framework as an off-the-shelf solution to scalability, and focus instead on the content of the service being developed." In other words, the image reduction performed by TranSend is just application written on top the cluster architecture. In fact, once the TranSend architecture was in place, each of the image distillers only took an afternoon to implement. This type of network application infrastructure can be extended in interesting ways... Imagine a server-side keyword filter that automatically enlarges and colors user-defined keywords on any page on the net. Or a service that enables proxy subscribers (say, employees in a corporation) to add commentary directly to any page on the web...which would only be viewable to subscribers to that proxy.

Or, how about a service that optimizes web browsing for very thin clients, say, clients as thin as your shirt pocket. The GloMop team is developing "TopGun Wing Man," a web browser for the USR PalmPilot, which works in tandem with the TranSend proxy. Since the Pilot has limited processing power and memory, the GloMop team has shifted the majority of the "work" of web browsing to the network. This implementation dramatically shrinks the amount of code needed on the Pilot, since the processor intensive tasks of parsing HTML and processing images are done on the network, where cycles are cheaper. Web pages are thus "spoon-fed" to the Pilot as compressed screen-draw instructions, which greatly reduces data transmission times.

I wouldn't be surprised if the TranSend service and cluster architecture is soon commercialized...Professor Eric Brewer is head of the GloMop team, and he's currently doing double duty as Chief Technology Officer at Inktomi. The TranSend architecture would be perfect for a large Internet service provider that is looking to extend their business into network computers or other thin clients, or provide value-add services by transforming web content on the fly for their end users.

While for most users I still consider the network computing model flawed, the TranSend team has demonstrated that for some types of client machines it makes sense to extend the functionality of the browser (or other network application) out into the network, where processing cycles can be used to overcome deficiencies in the client.

Many thanks to Armando Fox of the GloMop team, and Paul Haeberli of SGI for their ideas and input on this piece.



Other pieces about server-side software: