Tony Dodd wrote:
Adrian Chadd wrote:
Ok cool. Now, the techie questions:
* according to the draft, the port isn't used as part of the hash, is
this
right?
Indeed; and there's no newer version of the draft, unfortunately.
According to CARP draft v1, the only place the port is stored, is in the
ASCII Proxy Array Membership Table.
For anyone who hasn't seen the draft, it's available at
http://www.linofee.org/~jel/da/mmb99/7/CarpSpec.html
Squid is a little different in its peer requirements. The peering needs
to be anchored off the name= parameter or in the absence of that the
peer ip/fqdn given. In squid THAT must be unique for several other
indexes similar to this.
There is no requirement in squid that the IP/http-port combo be unique
because the IP/icp-port combo may be the difference.
* is just adding the port to the hash the "right way" of doing it?
(its a hash, so you want to create even distributions..)
no. see above.
name= being more arbitrary could be more even in best-case than port,
worst-case is about the same.
I think it's important to get the port involved in the hashing as early
on as possible, as the CARP mechanism is based off adding a URL hash +
proxy hash together to achieve a high score.
True enough, just the port being the wrong anchor for squids peering table.
Equally, there's the issue
of getting a wide enough hash distribution; however, looking at the data
I'm logging, with the combination of URL+proxy hash, the results are
extremely wide and varying, so I don't think it is breaking anything -
that said, it is 7am, and I am tired, so hopefully someone else can
agree/disagree on this point.
* do people have a problem with this going into squid, with relevant
documentation
being written about how CARP has been "extended" like this?
A hash alteration is clearly needed, just the details of what.
Amos
--
Please use Squid 2.6STABLE17 or 3.0STABLE1.
There are serious security advisories out on all earlier releases.
