Re: Feature: quota control

On Mon, 30 Mar 2009 11:38:31 -0600, Alex Rousskov
<rousskov_at_measurement-factory.com> wrote:
> On 03/30/2009 03:16 AM, Pieter De Wit wrote:
>
>> 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.
>
> We already have such a plugin API for message- and content-related
> tasks. It is called eCAP, and it has been mentioned on this thread.
>
> Compared to eCAP, traffic shaping and quotas are different in scope as
> they work on multiple messages and often do not care about the messages
> at all (just raw bytes traffic). So, we have a few options:
>
> 1) Use eCAP nearly "as is" for traffic shaping and quotas, even though
> it is not a perfect fit for the task.
>
> 2) Significantly enhance eCAP to offer traffic shaping-specific hooks
> (as a standard addition or as a Squid extension), even though it may
> lead to eCAP API bloat.
>
> 3) Develop a different plugin API that specializes in aggregate traffic
> management and is unrelated to eCAP, even though it may lead to
> duplicating a lot of eCAP-related code.
>
> I am not sure, but I think option #2 is the worst. What do you think?
>
> Cheers,
>
> Alex.

Hey Alex and List,

Sorry that I didn't read up on eCAP before starting this process, but I
believe that it won't be on the TODO list if eCAP "does it right". What I
saw in my mind is something like this :

Client/Bandwidth limiting registers with squid
...
squid get a request to download object x from site y by user z at ip
a.b.c.d etc
squid sends that request to the client (just "text" not the object)
client replies "yes" or "no" - if yes the client needs to track how much
data is left for that user etc.

(Client here is the limiting software - couldn't think of a better
name...coffee....)

I feel this should be a persistent connection that is matched by an acl for
speed etc.

Now to the workings of this. I am leaning towards option 3. I am not sure
how hard it is to maintain "two" API's. To be honest, I am not even sure
how hard it is to maintain one API. I feel that this really only needs two
or three commands, so is it really going to bloat the API ?

Broken down - what is the most "this API" would need ?

Cheers,

Pieter
 
>
<snip - I am sure they can find the follow up in the archive :)>
Received on Mon Mar 30 2009 - 19:03:21 MDT