Hi Martin,
Some comments below...
On Tue, 19 Jun 2001, Martin Stecher wrote:
I was thinking about this for a long time. Am I right that the ISTag is not
a MUST according to the draft?
Hmm... I think the idea was to mandate its use, although now that I am
checking section 4.7, nothing is explicitly stated (bug!). It is only
mandatory for the OPTIONS response (section 4.10.2)
Yes, I find the ISTag idea very useful but I think there is something
missing to help a client to invalidate the data correctly.
Imagine that there are two iCAP servers running the same service in some
kind of load balancing mode. Now the configuration of the service changes in
a way that should invalidate cached data. This will not happen on both
servers at the same time. Let's assume that there is a 2 minute delay to
update the second server after the first one in this example.
During this time the client will receive two different ISTags. Which one is
the newer, the valid one? What happens if there are more than two servers,
more than one update at a time, 3 or 4 different ISTags for one service?
First I thought the answer should be a numerical order of ISTags so that the
client has a better chance but today I got a new idea when discussing this:
If the iCAP client sends the ISTag which it has stored as the current one as
a header value in its REQMOD and RESPMOD requests to the iCAP server, the
service itself has a chance to decide what to do and it knows the possible
problem better.
The service is able to understand the semantic of the ISTag while for the
client this value is opaque. The service will know from a different ISTag
than its own one that there is a sibling running with a different software
version or configuration. And so the service has a chance to react on this
if its ISTag is the older one. It could either try to get the configuration
data from its sibling automatically or it can reply with a
currently-out-of-service response and wait for the update or it can return
its normal response but add a pragma no-cache to it to indicate that its
data is not worth to cache. After the update coming soon the response will
change anyway.
I don't say that the ISTag in the requests should be forced with a MUST. But
I think it makes sense to allow and encourage them in the specs. It will
also strengthen the cookie similarity.
What are you thinking about this?
Escpecially the cache vendors. What will you do with the cached contents if
the iCAP service changes in a significant way? How will you face different
versions inside a iCAP server cluster during an update process?
There may be multiple ways to solve this issue. For example, you
could have a "voting algorithm" to deal with ISTAG changes in a
service farm (this is what NetApp is doing I think). Basically, the
majority of servers that have the same ISTAG win the selection
decision. When administrators finally update all the servers, the new
service (as a whole) will be used.
Having said that, I don't think this issue belongs to the
specification of the transport protocol, which should be kept as
simple as possible to do its job and no simpler. Different
implementors may want to deal with the problem differently. I would
be willing to include a subsection 8.x explaining this issue, but I
don't think we should mandate anything in the protocol per se. That
should be left to the implementor's discretion.
Thanks for you comments!
Regards,
-Al