[Kamailio-Users] [sr-dev] ratelimit enhancements

Henning Westerholt henning.westerholt at 1und1.de
Wed Feb 3 19:01:21 CET 2010


On Tuesday 02 February 2010, Ovidiu Sas wrote:
> 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.

Hello Ovidiu,

i agree here with you.

> 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.

This is not a problem when you make this exclusive, either config file or DB 
mode, like in cr.

> Having the ratelimit configured via module parameters is forcing
> changing the config file every time the default rate limits are
> changed.

The ratelimit supports changing with FIFO commands. 

> 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;

Well, this is also true for the configuration 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.

discussed above

> 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:

Hm, it seems that the logic is not that big that moving this to a library is 
strictly necessary. The complete module is only about 1.5 kLOC. The dbtext 
module is about 3.5 kLOC, for comparison. In my opinion a switch like 
"config_mode" could be a good option and should hopefully be not that 
intrusive in the implementation.

Just some arguments from my side why i not like the dbtext approach that much. 
We've processes and tools for packaging and deploying our configuration to the 
servers, we need to adapt documentation and get operational experience with 
the new database module. So this work i'd like to avoid, especially if I only 
want to provide a few lines of configuration data. I also don't want to run 
into eventual corruption problems in the database during an failover situation 
or a watchdog restart of a loadbalancer.

But, moving a bit away from this argumentation, i thought that this discussion 
was about an eventual replacement of ratelimit with the pipelimit module? As 
long as the ratelimit module is available i don't worry about if the pipelimit 
support only DBs, as we don't have too advanced requirements in this regards.

Best regards,

Henning

-- 
I'm going to FOSDEM
6. - 7. Februar, Brussels



More information about the Users mailing list