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

Thanks, Henrik pal!

You have clarified all my doubts. :-)

Best regards,
George Ma

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

> 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 - 19:56:38 MDT