Caching Strategy

The caching strategy determines how the News Cache handles read and write requests. Read requests are usually fulfilled immediately. It is obvious that delaying a read request is undesired, because the client needs to poll for the data since they are available. In the case of the News Cache, the News Cache has to inform its user that the requested data are currently not available, but it will be requested from the actual data source. This strategy is not satisfactory for the following reasons:

• The user has to select a newsgroup twice. The first selection is necessary for the cache to request the data of interest, but does not provide any information to the user.
• This strategy is difficult to implement, because no satisfying solution exists to inform the user that the articles of the newsgroup are not cached currently. This could be done by using a fake article informing the person reading news that the newsgroup's articles will be available in some minutes. However this will confuse the news reader's database of read and unread articles.
• The cache server should be fast and only small delays should occur for data not available in the news cache.

The News Cache presented in this thesis fulfills read requests immediately.

Similar strategies may be used for post requests. Either they may be fulfilled immediately like read requests or they may be spooled and fulfilled later on. It does not matter if post requests are spooled and fulfilled with a delay, because usually the reader does not need to access the article immediately after it has been posted. For postings the following strategies can be distinguished:

Post Through

means that whenever an article is posted, it is posted directly to the news server and not stored within the News Cache. The advantage of this method is its simplicity. The News Cache does not need to maintain the postings in any way. However, if the connection to the news server is lost, the posting of the article will fail and it has to be reposted by the user.

Buffered Post Through

eliminates the problem of the previous strategy, because all post requests are stored locally. As soon as a connection is possible to the news server, the article will be posted. This gives the impression to the client that the posting succeeded even if the request cannot be processed immediately.

However, articles spooled to post to the news server are not available from the cache till the article has been posted to the news server, because post requests are stored in a queue independent of the newsgroups.

Buffered Post Back

eliminates the small problem of the buffered post through strategy at the cost of additional complexity. Posted articles that are only stored on the cache server can already be served to its clients, because they are merged into the local article spool.

Whenever an article is posted, it is immediately accessible via the requested newsgroup and has to be assigned an article number. However, this means that the news cache has to use its own article numbers for all of its articles and has to maintain a mapping between the article numbering on the News Cache and the news server.

We think that the News Cache should use either Post Through in combination with Buffered Post Through as fallback strategy in case the news server cannot be reached or Buffered Post Through . We discourage the use of Buffered Post Back strategy. Since this method uses local article numbers depending on the arrival order of the articles, the user cannot switch between different News Caches attached to the same news server. The problem arises from the fact that most news readers need the article numbers to remember which articles have been read.

Compared to the Post Through strategy Buffered Post Back has the advantage that post requests can always be handled. If the news server is accessible they will be sent to the news server directly. Otherwise, they will be spooled till the news server is accessible.