4 Feb
2010
4 Feb
'10
1:15 a.m.
On Feb 02, 2010 at 13:41, Ovidiu Sas <osas(a)voipembedded.com> wrote:
Hello Henning,
Having both method of initialization will just complicate the code.
When the module parameters are parsed, the shared memory is not
available and therefor all the module rate limit parameters will need
to be cached into the memory until the shared memory is available.
The shared memory is available for module params (recent change).
New code needs to be added to deal with conflicts when
both method of
initialization are provided: init via db and init via module
parameters.
Having the ratelimit configured via module parameters is forcing
changing the config file every time the default rate limits are
changed.
One could change them via rpc/fifo/mi at runtime, without restart.
Using the simple db_text module has a lot of
advantages:
- db_text is available for all platforms;
- the database is used only during init, after that the database is
no longer used and therefor there is no impact on performance;
- the rate limits are stored in human readable text file;
- a database reload feature can be added and the default rate limits
can be changed without touching the config file and server restart
will keep the new settings.
These are just my observation from using heavily the existing ratelimit module.
If specifying the rate limits in the config file is a must, I would
recommend keeping both modules and moving the common code into a
library:
- ratelimit with config init
- pipelimit with db init
I would prefer having the option of using modpram+rpc method instead of
db.
Andrei