Hello, all -

I'm running into some issues where I can't quite seem to get HTCP to
work properly.  I'm using 3.0STABLE5-2, with HTCP enabled at compile
time, and although I have Squid set up properly working as a stand-alone
reverse proxy cache, I cannot get one node to talk with another.

So far as I understand, this should be the 'meat and potatoes' of what
makes HTCP tick:

cache_peer 239.4.8.12 multicast 80 4827 ttl=1
cache_peer 192.168.15.75 parent 80 4827 htcp no-query originserver
name=localhost.localdomain
cache_peer 192.168.15.85 neighbor 80 4827 htcp multicast-responder

mcast_groups 239.4.8.12

- noting my multicast address as 239.4.8.12, with a negligible http
port, making sure to use HTCP (implied with port 4827 as ICP port) with
a TTL to live.
- parent cache peer of 192.168.15.75, http port of 80, making sure to
use HTCP (implied with port 4827 as ICP port), making this the final
destination for queries
- neighbor cache peer at 192.168.15.85 configured to participate in the
multicast group and respond appropriately

Now, those are my interpretations of the process.  Of course I have a
few other ACLs in there that also manage suqid in itself, but I'm not so
sure they're directly related to this.

I guess what my question is, is that I am having a bit of difficulty
understanding which peer can be told to be the final destination for the
request, i.e. that peer being the backend web server.  Once I get that
figured out, I believe that I can make all other peers neighbors
(right?), which use that final destination to populate their cache.

I hope I'm explaining this properly, I might be a bit off here.  I
suppose other than that, my first day using Squid has been a lot of fun!

Thanks!
-dant

Reply via email to