On 07.05.2012 07:15, x-man wrote:
Amos Jeffries-2 wrote
On 02.05.2012 03:12, x-man wrote:
Hello,
I have this question:
If you have squid, that is working as intercept proxy for
customers,
has
parent cache_peer (non-squid), who is not talking ICP or HTCP
procols, and
is only dealing with part of the content.
How this parent cache_peer will communicate to the main SQUID about
if the
request is MISS or HIT, as I want the main squid to apply packet
mark for
the HIT traffic.
Or the marking should be done on the cache peer level?
It is best done at the node which has all the information. Things
are
not really as simple as HIT/MISS.
You will also need TOS pass-thru features enabled in the kernel to
propigate the TOS from the squid-upstream packets to the
client(s)-squid
packets. Although in you could also map the upstream TOS to a
netfilter
MARK value and pass it through Squid then map it to TOS value on the
other connection(s).
Amos
If I mark the packets from the cache_peer with netfilter mark, will
the
squid preserve it? In this case do I need some kernel
modifications?!?
If it was MARK'd on the same machine,the new netfiler MARK extensions
to ZPH QoS will preserve it same as they do for TOS preserving. But
without needing kernel patching and custom Squid build like TOS preserve
does so far.
I wonder if there is any simple way that the cache_peer will tell the
MAIN
squid that this is HIT and the main squid (who is replying to the
customers)
will MARK it with proper TOS? Any way.. be it with protocol or not.
The conceptual problem is that HIT/MISS is *only* a terminology
distinction relative to the particular cache doing the processing. There
may be multiple caches involved and a request might be a HIT on one of
them and MISS on all the others. Everything is a HIT on origin servers,
but may be a HIT or MISS on surrogate servers (reverse proxy).
Taking the idea to its conclusion everything is therefore a HIT,
because at some point down the chain it was a HIT.
I know you have a simpler usage case where things are clearer, but the
above should help explain why this is a hard problem for Squid to "just"
have a config for.
Waking up;
fully internally to Squid we have the X-Cache: header at present
being emitted with HIT/MISS details. You may be able to setup a
rep_header_regex ACL the scans for HIT and your upstream cache name.
Used on tcp_outgoing_tos to set TOS value. This is not a completely
reliable header though, there will be some false matches or failures
using it at present and future plans are to remove it from most traffic.
Amos
