Hi Guys,
I gave this some thought. Why don't we build a system close to sendmail's
milter system. An API where by clients can plug in and offer services - one
can be a traffic counter, traffic limiter (as what we proposing here) and
maybe a URL block, a virus scanner etc.
I know that there are re-directors that do this kind of thing, but surely
squid has reached a stage now where it's big enough to expand this way ?
Sendmail had to end up doing it ?
It might even give a solution to the "single thread disk problem" since you
could have your disk stores register in the same way. I am just thowing
ideas around - maybe they should be targeted for Squid 4, who knows :)
What you guys think ?
Cheers,
Pieter
----- Original Message -----
From: "Adrian Chadd" <[email protected]>
To: "Amos Jeffries" <[email protected]>
Cc: "Robert Collins" <[email protected]>; "Mark Nottingham"
<[email protected]>; "Pieter De Wit" <[email protected]>;
<[email protected]>
Sent: Saturday, March 28, 2009 5:31 PM
Subject: Re: Feature: quota control
Just to add to this - implementing it as a delay pool inside Squid
flattens traffic into one byte pool. Various places may not do this at
all - there may be "free" versus "non-free" (which means one set of
ACLs inside Squid); there may be "cheap" versus "expensive" (again,
possibly requiring multiple delay pools and multiple ACLs to map it
all together; again all inside Squid) - things get very messy, very
quickly.
This is why my proposal (which I hope -finally- gets approved so I can
begin work on it ASAP! :) involves passing off the traffic assignment
to an external daemon that implements -all- of the traffic assignment
and accounting logic. Squid will then just send requests for traffic
and interim updates like you've said.
2c,
Adrian
2009/2/26 Amos Jeffries <[email protected]>:
Robert Collins wrote:
On Fri, 2009-02-27 at 10:00 +1100, Mark Nottingham wrote:
Honestly, if I wanted to do byte-based quotas today, I'd have an
external ACL helper talking to an external logging helper; that way, you
can just log the response sizes to a daemon and then another daemon
would
use that information to make a decision at access time. The only even
mildly hard part about this is sharing state between the daemons, but if
you don't need the decisions to be real-time, it's not that bad
(especially
considering that in any serious deployment, you'll have state issues
between multiple boxes anyway).
Sure; I think that would fit with 'ensuring enough hooks' :P
-Rob
The brief description of what I gave Pieter to start with was:
A pool based on DelayPools in that Squid decrements live as traffic goes
through. With a helper/ACL hook to retrieve the initial pool size and to
call as needed to check for current quotas.
How the helper operates is not relevant to Squid. Thats important.
The key things being that; its always called for new visitors to assign
the
start quota, and when the quota is nearing empty its called again to see
if
they get more.
Helper would need to send back "UNITS AMOUNT MINIMUM" where UNITS is the
unit of quota (seconds, bytes, requests, misses?, other?), AMOUNT being a
integer count of units the client is allowed to use, and MINIMUM is the
level of units where the helper is to be asked for an update.
0 remaining units results in an Error page 'quota exceeded' or somesuch.
Amos
--
Please be using
Current Stable Squid 2.7.STABLE6 or 3.0.STABLE13
Current Beta Squid 3.1.0.5
