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).
Squid modifications that would help this (and similar use cases):
1) Allow multiple, different external loggers to be defined and used.
2) Harmonise the interfaces/configuration of *all* external helpers,
so that you can pass arbitrary args to each, using the same syntax.
I'm looking at you, redirectors.
3) Reduce the overhead of using external helpers, if possible.
A *lot* of the customisation that I do for Squid is based on uses of
helpers like this; they're actually very powerful and flexible, if you
know what you're doing with them. I would very much like to see Squid
turn them into more of a strength...
On 27/02/2009, at 9:30 AM, Robert Collins wrote:
Key things I'd look for:
- quota's shouldn't be lost when squid restarts
- people should be able to use external quota systems (they may have
e.g. netflow or other systems tracking direct b/w use, and squid
is pulling from those allowances when downloads are caused by a
given user).
Both of which are nicely solved by Adrians suggestion of making sure
there are appropriate hooks in squid to let other software actually do
quotas.
It would be nice to ship a default client for those hooks that does
something simple (like monthly quotas with a simple script to report
on
current totals/reset). But even that is probably too much in core - it
should probably be a parallel project, like the reference icap client
is.
(And isn't iCap enough to do quotas?, or is it too heavyweight?
Perhaps
look at the in-squid iCap-alike Alex has been working on?)
-Rob
--
Mark Nottingham m...@yahoo-inc.com
