On Opaque validators

I believe that ``opaque validators'', as presented in
http://ftp.digital.com/%7emogul/cachedraft.txt (2.6), do not work
for the best in some circumstances. Specifically I believe that
validators should be chronologically ordered and that such a order
should be known to caches and clients.  This way caches and clients
can know which one between two copies of the same object is older,
that helps in a number of situation (I believe).

I try to enlighten the problem by means of a couple of examples.

 (A)    Suppose to have a peer-entity caching mechanism (like the
	one present in Harvest). In such a scheme, a cache is allowed
	to look for the missing object in a pool of neighbor caches,
	by means of a multicast request, and to chose the best hit
	(if available). Then, if multiple (fresh) hits with
	different `Cache-validator' value are returned (*), the cache
	should have a way to chose the best hit (the newer object).


 (B) 1) cache-"a" and client-"b" have two different copies of the same
	object with `Cache-validator' Xa and Xb, and expiration time
	Ta and Tb respectively (client-"b", for some reason, fetched the
	object from a different source than cache-A).
     2) Suppose client-"b"'s copy being the newer one, but Tb<Ta (*).
     3) at time T (Tb<T<Ta) client-X issues a conditional GET to
	cache-"a", which in turn replies with its own copy of the object
	being it fresh and being Xa!=Xb.
  Note that, this way, client-"b" retrieves an older copy than the one it owns.

(*) the only way to avoid that is to forbid a server to generate
    a new validator when still exists a fresh copy of the object with
    older validator.

A proposed solution: ``semi-opaque validators''

Each server generates its own validators using its own algorithm...
...then attaches to validators an ordering prefix.

This way: 
  * the composite validators are chronologically ordered for
    caches/clients comparison purpose;
  * servers are free to ignore the prefix when comparing validators;
  * faults 1) and 2) in (2.6) are overcome;



	Lorenzo.

<|--------------------------------------------------------------------------|>
 | Lorenzo Vicisano                     | http://www.iet.unipi.it/~vicisano |
 | Dip. di Ingegneria dell'Informazione | e-mail vicisano@iet.unipi.it      |
 | Universita' di Pisa                  | Phone  +39-50-568654              |
 | Via Diotisalvi, 2 56100 PISA, ITALY  | Fax    +39-50-568522              |
<|--------------------------------------------------------------------------|>

Received on Monday, 8 January 1996 19:10:06 UTC