The previous chapter discusses repositories.

Caches

The purpose of a cache is to deal with the current cost structure of the telephone network. Roughly speaking, the telephone network bases its charges as a function of the connection time, connection distance, and the time at which the connection is established; there is an additional monthly fee that is accessed independent of whether the service is used or not. A cache reduces the overall cost for accessing information by enabling the user to have a long term connection to the cache which is located locally and share the costs of the long haul connections to repositories with other users. In addition, most users will only be able to have one or two simultaneous telephone connections, whereas a cache will have much more connectivity with the telephone network.

Caches will work best if the total number of repositories is fairly limited; otherwise, the cache will constantly be initiating and breaking connections with other repositories as they are needed and they will not be saving very much on connections costs.

There are some additional tricks that can be used to reduce cache costs further. For example, a metropolitan area may have a multi-level cache system in place whereby each telephone exchange has a cache and each of these exchange-level caches has a connection to the metropolitan cache. With current billing practices, this architecture can reduce the user to exchange level cache connection costs to zero; presumably, the telephone company will eventually attempt to rectify this billing loophole. Another trick is to take advantage of rate differences. If a connection is established at a lower rate (e.g. the late evening rate), the rate will currently continue into the prime-time rate. While it is fun to think of ways of thwarting the telephone companies billing system, eventually the telephone company will be justified in trying to close the billing loopholes; after all, the telephone company is not in the business of selling telephone services below actual costs. Conversely, electronic publishing services are equally justified in trying to ensure that they are not unfairly billed for the services utilized.

There are a number of different cache billing strategies:

A cache can charge for local connect time.
A cache can charge directly for long distance phone costs incurred on behalf of the user; for this billing strategy, people will can reduce costs dramatically by using cache services off hours.
A cache can charge some sort of flat monthly rate.
A cache can offer reduced fees for students.
etc.

Obviously, whatever billing strategy a cache adopts will have to cover actual costs or the cache will go out of business.

In general, all a cache needs to do is implement a least recently used (LRU) cache of read requests. Whenever the user asks for an information span, the cache can see how much is in its LRU cache and issue repository requests for whatever is not in the cache.

Whenever there is a cache, cache coherency needs to be addressed. For read-only documents that will never change over time, cache coherency is pretty easy in that if the data is in the LRU cache, it is up-to-date. This suggests that repositories should never attempt to reuse bit spans, but instead always issue new documents in new spans. However, index search trees and royalty entries can be updated, so additional cache coherency mechanisms are needed to ensure that the viewer software does not get stale data. The proposed scheme is to always associate a recheck date with information spans. The cache would ang onto these recheck dates for all information. Whenever the recheck date expires for a particular span, the span is deleted and refetched. Thus, read-only spans would have a recheck date set to infinity and read-write spans would have a smaller recheck date. For example, a repository might only permit authors to change their royalty rates once a month, thereby permitting royalty spans to a recheck date that only changes once a month. It does not particularly matter what cache coherency scheme is adopted, just so long as all caches never present stale data to users.

There is an architectural issue of whether data spans in the LRU cache result in royalty payments to the author. It is certainly simpler architecturally if the cache does not have to pay any such royalty. However, heavily accessed documents such as newspapers will get a very small amount of royalties if this strategy is adopted. Thus, it appears that caches will have to charge the royalty each time a user accesses a data span independent of whether it is in the LRU cache or not.

How does one guarantee that caches are honest and pass royalties collected from users for LRU cache hits onto the repositories? It is extremely tempting for a cache implementor to attempt to redirect these royalties into its own coffers. One strategy is for repositories to police caches by connecting to a cache and making repetitive accesses to repository information to verify that all of the appropriate royalty payments occur. Another strategy, is to reward viewer software somehow to occasionally directly call up the repository and tell the repository exactly how much royalties were payed during a particular period; if the repository ever detects a discrepancy, they can stop accepting requests from a particular cache. Again, it does not particular matter how cache honesty is policed, just so long some mechanism is in place to do the policing.

Like repositories caches have support a great deal of I/O bandwidth. Caches must have enough network connections to support most their users most of the time. In addition, caches must have enough additional network connections to use for connecting to repositories. Finally, caches need enough access to read/write storage to store commonly accessed information. While small caches will be able to make do with a single processor implementation, the larger caches will require multiprocessor based implementations.

You may go to the next chapter discussing electronic banking or back to the table of contents.