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

[Daniel-Constantin Mierla]

summarizing, I am going to merge pipelimit as separate module for now. 
The future will dedice if both worth to keep or one will take over the 
other.

Cheers,
Daniel

On 02/04/2010 05:15 AM, Ovidiu Sas wrote:
> The major disadvantage that I encounter with modparam (in the current
> ratelimit module) is related to changes done via rpc/fifo/mi: on
> server restart, all these changes are lost (unless the config is also
> updated).
> I much prefer to have the ability to change the db and then perform a
> reload.  This will ensure the same behavior on server restart.
> One may argue that it is the same with modparam, but the difference is
> that changing the config and performing changes via rpc/fifo/mi
> interface are two independent operations vs changing the db and after
> that perform a reload, which is a cause/effect operation, ensure
> synchronicity between server restarts.
> I also much prefer to have the ability to create a generic config file
> and customize the deployment via the db.
>
> Maybe keeping the ratelimit as is and having the pipelimit with db
> only config will be the best solution for now.  It time, we will see
> which one has more traction.
>
>
> Regards,
> Ovidiu Sas
>
> On Wed, Feb 3, 2010 at 6:15 PM, Andrei Pelinescu-Onciul
> <andrei at iptel.org>  wrote:
>    
>> On Feb 02, 2010 at 13:41, Ovidiu Sas<osas at 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
>>
>>      
> _______________________________________________
> Kamailio (OpenSER) - Users mailing list
> Users at lists.kamailio.org
> http://lists.kamailio.org/cgi-bin/mailman/listinfo/users
> http://lists.openser-project.org/cgi-bin/mailman/listinfo/users
>
>    

-- 
Daniel-Constantin Mierla
Kamailio SIP Router Masterclass, Berlin, March 22-26, 2010
* http://www.asipto.com/index.php/sip-router-masterclass/