httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From a...@foogod.com
Subject Questions about filter placement
Date Thu, 29 Aug 2002 11:53:25 GMT
Greetings all,

A little while back I started working on a module to control bandwidth
utilization with rate limiting, employing fairly flexible configuration and
some other nifty features..  At the time it became clear fairly early on that
it would be much easier to do this properly within the 2.0 API than the
then-current 1.3 server, but the 2.0 API was still somewhat in flux, so after
looking into things a bit I decided to hold off for a little while and come
back to things later.

Now that things are somewhat more solidified I'm coming back and looking at
this project again, but I'm still running into a few questions with the current
2.0 API that I was hoping some folks here could provide some
insight/suggestions on..

>From what I've read about the 2.0 API, this application (rate limiting of
server output) seems perfect for an output filter.  However, one of my first
questions centers around where in the filter chain behavior such as this should
go.

Obviously, in order to function properly, this filter should come after any
content-modifying filters in the output chain.  Given the fairly low-level
nature of what it's doing (controlling network traffic) it seems to me that it
really makes most sense to put this somewhere in the AP_FTYPE_CONNECTION, or
possibly even AP_FTYPE_NETWORK part of things, however it's my understanding
that connection and network filters do not have access to any information about
the request, and since the bulk of deciding what rate limits are to be imposed
for a given hunk of data is going to be determined by per-resource
configuration, this presents a problem.

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.

Ultimately, what seems like the most correct solution I can see would be to
implement this in multiple stages, with one content_set filter used to
determine the appropriate limits for a given set of data, and then a later
filter actually controlling the output rate of that data when it's closer to
going out over the network.  The problem with this is that I can't see any
obvious way for the earlier filter to communicate what it's decided about the
given data to the later stage for acting upon.  Is there any way to "mark" data
going out from one filter with information that can be used by a later filter
when it gets that data to work on?

Anyway, does anybody out there have suggestions on the best approach to use for
this application?  Where should code to control data flow rate go in the filter
chain, and if that place isn't in a request-related filter, is there an easy
way to make request-level decisions related to that filtering?

Thanks,

-alex

PS: As this subject seems to be a hotbutton for some people (at least it was
the last time I brought it up on this list), please don't just respond to this
by saying "why would you want to do that?" or "bandwidth limiting doesn't
belong in the httpd server!" or "people have already made things that do that"
or similar things.  I've had all these discussions before, and I have good
reasons for making this module that I'll be happy to explain to people in
private if you really want to understand where I'm coming from with this, but
ultimately it boils down to:  Yes, this is required to do things which you
really can't do other ways and is potentially very useful.  No, nobody else has
already done it with the capabilities I'm looking for (I've checked).

Mime
View raw message