![]() Houston. Anyone . Everyone. Do You Copy? More systemic approaches include Datal ytics' Blaze Web Performance Pack, a local proxy cache that adds server-enabled compressed and bulked HTTP transfers. Certainly one exacerbating issue in performance is the site designer's propensity for more than a few (big and little) graphics but also for animations and soon more applets and scripting. All of this means a page isn't just one thing but a whole set of things, all being downloaded from a server over the network. Such complex sets of objects take quite some time and eat up server resources, particularly given session-less HTTP protocol's TCP/IP connection overhead for each downloaded object. Datalytics' xSpeed technology offers an approach that bundles all that into a single larger object that is more efficiently downloaded. Updates to HTTP, plus the possibility of WebNFS as a replacement for HTTP, also could make page downloading more efficient on servers, clients and networks. Copy in the Middle A more intelligent choice, and frankly one much easier to manage for corporate implementations, is a server-based proxy cache solution. Netscape's first proxy server was just an intermediate copy location. Throw enough fast disk at the problem, and it would make a significant dent in the utilization of the T1 to the Internet. The advantages of caching between the Web server and the Web browser is great. If multiple users request the same page, that page will traverse the Internet link once. Sending data once only over shared network links to multiple recipients or requestors is always a good idea. Multicast IP is a network-level approach to this, but it doesn't work for request/reply-oriented applications like the Web--yet. Application-level solutions like push or Web-casting solutions (PointCast, Marimba and BackWeb, to name a few) sometimes attempt to be smart about moving data once per link (however, as previous columns have pointed out, pushing doesn't always come to real shoving). Even if the data eventuall y must be repeatedly pulled in by each client over the same subnetwork, at least t hat could be over individual LANs while the one-time-only delivery occurs over the more costly and more congested WAN link. In fact, you can do both server and client caching. Let the individual solutions handle the true offline case. Let the server solutions handle the more general network-load case. Interestingly enough, all the fancy features we see being developed on single-user solutions will migrate to the multiuser products over time. Microsoft's Proxy Server (code name Catapult) offers automatic preload intelligence. It notices what users ask for most often and pre-fetches those pages from the Web. (Isn't automatic intelligence in software an oxymoron?) Netscape is offering more scripting to allow administrators to configure preloading proxy servers. Indexing servers and more permanent caching will certainly come. Copy Politics A recent development in the technology of copying has been the World Intel lectual Property Organization (WIPO) discussions on content ownership policy. At one point during the worldwide copyright definition process, there was language indicating that it would be illegal to make even transitory copies of data without permission and/or payment. This would have made unintelligent caching illegal. The final version of the referendum now only focuses on more permanent copies. Yet, this still affects those copies made for longer-term storage in offline caches. These are more permanent copies. Are we moving toward more discussion about when copying is allowed and when it is not? Yes, I think this issue has not finished rearing its ugly head. Over and over again, we'll see problems of data-access performance and data availability solved by making more local copies of distant data. That way original servers are off-loaded, while some, if not all, of the network is spared some traffic (depending on the location of the cache). With cachable Web content (and not all content is--individual queries to databases are not going to be reused) basically easy to track for changes, th e problem of stale data in the copy is easy to handle. With internal systems, data ownership isn't so much of a problem. With external systems, when users are querying data from servers worldwide, there is bound to be data not owned by the company being viewed not only by internal users, but even copied by those users on a permanent basis. We have to face the fact that once atoms become bits (Nicholas Negroponte's famous point in Being Digital), that bits can be easily copied. Even atoms can often be easily copied, to which the fortunes of Xerox and Kinko's can attest. Once those bits are owned, copyrighted and charged for, the issue becomes more problematic. There are also security and privacy issues to contend with (who can see that data in the cache?). In the end, as Web content gets more complex and less anonymous, proxy caching brings up as many problems as it solves. We'll want more controllable caches of dat a. We'll want more of what Lotus Notes can do than a normal proxy server (or offline browser cache). The more intelligent we make the caches, the closer they get to being full-fledged server replication solutions. There is no perfect cache. And, no, "Roger, Houston" is not a suburb here. Bruce Robertson is a program director with the META Group's Global Networking Strategies service. He can be reached at BruceR@metagroup.com. |
![]() |
by Patricia Schnaidt FreeWire by Bill Frezza Coporate Vie w by Brian Walsh On The Wire by Bill Alderson and J. Scott Haugdahl Updated February 21, 1997 |














