Re:Re:Re: Puzzled at flags.hierarchicala and neighbors_do_private_keys after reading FAQ. :-(

Thanks, Henrik pal!

I still have a question. In the past, I think private and
public keys has the following meaning as you mentioned,

> having a private key is private to their user (cannot be shared), and
> objects having a public key is shareable, allowing cache hits.

The key value is the result of MD5 algorithm with 16-byte length.

But I think the "key" term in neighbour_do_private_keys has a different meaning
of the key. It seems like it is the index of the ICP query and has nothing to do
with the object. The "key" here has nothing to do with the private key of the
cached object? It is just a field of ICP? I have read the FAQ
"12.32. What does ``Disabling use of private keys'' mean?". I think it is the
reqnum field.

My question is, is the ICP ( maybe reqnum )field has something to do with the private key which
is genernated by MD5 to index the cached object?

Best regards,
George Ma

----- Original Message -----
From: Henrik Nordstrom
To: maer727@sohu.com
Cc: squid-dev@squid-cache.org
Subject: Re:Re: Puzzled at flags.hierarchicala and neighbors_do_private_keys after reading FAQ. :-(
Sent: Sat Apr 20 18:33:53 CST 2002

> On Saturday 20 April 2002 07:40, maer727@sohu.com wrote:
> > Thanks, Henrik pal!
> >
> > I think when !flags.hierarchical is true, we should not send
> > request to any of the ICP peers and should send the request
> > directly to the server. Am I correct?
>
> Yes.
>
> > I still have a question. After reading "What does ``Disabling use
> > of private keys'' mean?" in FAQ, I am puzzled why a cache can use
> > an object with a private key in another ICP peer? I think the
> > object with private keys can only be shared by one user until it is
> > public. How can other peer ICP caches use an object with private
> > key?
>
> Because ICP has a field where the caller can store a private unique
> identified identifying the ICP query. From this we can then find
> which request (and StoreEntry) trigered the ICP query when receiving
> a ICP reply.
>
> If the other peer do not support this field, all we know when
> receiving the ICP reply is the URL of the object. This makes it
> somewhat tricky to identify exacly which request the ICP reply is for.
>
> Ignore the ICP interactions for now. Just remember that objects
> having a private key is private to their user (cannot be shared), and
> objects having a public key is shareable, allowing cache hits.
>
> Regards
> Henrik
Received on Sat Apr 20 2002 - 06:44:09 MDT