httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Werner Schalk" <>
Subject RE: Questions about filter placement
Date Thu, 29 Aug 2002 23:31:04 GMT
Hello Alex,

tell me more about your module.
Is it already available for testing
and apache2?

Bye and thanks,

-----Original Message-----
From: [] 
Sent: Friday, August 30, 2002 1:23 AM
Subject: Re: Questions about filter placement

On Thu, Aug 29, 2002 at 08:06:45AM -0700, Ian Holsman wrote:
> your trying to limit traffic based on what kind of request/request 
> path
> it has ?

Yes, actually based on vhost, URI, directory, file type, size, user,
time of day, etc, etc.. pretty much anything you can think of.  It also
supports multiple overlapping bandwidth restrictions and will restrict
traffic based on what other requests are currently being served to
ensure the cumulative rate for any given bandwidth limit is never

I've got the core code working in a test harness, now I just need to put
it into an apache module..

> > I could implement this as an AP_FTYPE_CONTENT_SET filter, which 
> > would make the most sense from a configuration and decision-making 
> > standpoint (since I have access to request information), but one of 
> > the questions I have about this is whether other buffering and such 
> > later in the filter chain (such as with transcode/connection/etc 
> > filters) would render any attempts at rate control at this level 
> > moot, or at least seriously degraded.
> yes, but from what I can see if you are trying to slow down the 
> request
> with your filter, this should not be a major drama.

Well, my main concern is if there are things down the line which buffer
large portions of data before sending them out, it would generate
"bursty" network traffic, which I want to avoid.  Part of the reason I'm
doing this is because I want to have more smooth control of network
utilization so it doesn't impact other services or requests..

I had seen some notes about the content-length filter, for example,
setting aside the entire response until it got the end of it, which if
my filter was before it would completely defeat the behavior of my rate

> if you are basing the rate limiting on something on the request I 
> would
> suggest you write a request hook, (somewhere after the request headers

> have been read.. forget the name for the moment) and make it set a
> in the connection record. (or maybe use the
> call it's faster)

Ah, thank you..  Yeah, I realize now I should have been thinking in
terms of a request hook rather than a filter for the decision-making
process, but aside from that little detail this is basically what I was
envisioning.  I wasn't aware of apr_pool_userdata_set or connection
record notes, I'll go look into that.  It sounds like it should do very
much what I'm looking for.

One last question:  Because it keeps track of what other requests are
currently being served, my implementation needs to know when serving a
request has been completed, as well.  Obviously, this could pose some
problems with coordination between when request-processing is considered
finished and when the data actually goes out over the net.  What I would
really like to do is consider a request "finished" once the last of its
data goes out.  Is there an appropriate hook or something for doing
stuff when this happens, or should I just look for an EOS or something
go through my limiting filter and do the processing there?

I'm still getting the hang of a lot of this architecture, but I'd like
to do things The Correct Way(tm) if possible :)

> The only potential downside I can with implementing it this way is if
> you have 2 small requests which get sent out together, you will get
> rate limit of the 2nd one.

As long as they're small, I don't think anybody will care that much, so
I can live with that.

Thanks a lot for the help,


View raw message