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

Yes. This also has effects on the ICP implementation of Squid and
how/when/why an object within Squid uses private or public keys.

If the peers do not support the reqnum ICP field, then Squid will
assign public keys to the StoreEntry structures belonging to requests
being queried over ICP. This because when the ICP reply is received
Squid looks for the StoreEntry to find the request initiating the ICP
query.

As I said, don't bother yourself too much on this small detail at
this time.

Regards
Henrik

On Saturday 20 April 2002 14:44, maer727@sohu.com wrote:
> 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 - 10:16:51 MDT