[Kamailio-Users] ratelimit enhancements

[marius zbihlei]

Daniel-Constantin Mierla wrote:
> Hello,
>
> On 1/22/10 3:31 PM, Ovidiu Sas wrote:
>> The way that the original module was written did not allow dynamic
>> numbers of queues and pipes.
>> I am using the ratelimit module to control incoming/outgoing traffic
>> on specific trunks by invoking rate limitation based on pipes (by
>> forcing a specific pipe).
>> Choosing a specific pipe is up to the kamailio config designer (any
>> type of operations ca be applied to the pvar before choosing a
>> specific pipe, so IMHO it is pretty flexible as is right now - one can
>> apply any regex operations to a pvar).
>> Pipes and queues can be dynamically modified via mi commands.
>> The major limitation of the module is the hard coded number of queues
>> and pipes and the fact that dynamic changes to pipes and queues are
>> not saved on restart.
>>
>> Loading the queues and pipes from a db will require a redesign of how
>> the pipes and queues are stored internally.
>>    
> yes, it is a hash table. A benefit of dynamic/dynamic names is you can 
> simply use ip address as pipe name. Also strings tend to look more 
> meaningful when coming back to a config after some time :-) .
>
> IIRC, one issue with the old design is using single lock for all 
> pipes. The advantage was using static indexing, therefore faster 
> access (still under one lock). The new one has a lock per slot, so 
> there can be quite some parallelism of updates/checks, therefore 
> overall could be same results, tending to be faster with old for low 
> number of pipes and not so heavy traffic, better with lot of pipes and 
> lot of traffic.
>
> On the other hand, I find useful what Marius proposed as new features.
>
> Cheers,
> Daniel
>
Hello,

I saw the pipelimit commit, and I am going to have a look to better 
understand the design.  The first question is about the new pipelimit 
module...
Does it require(as in it's a must) a working DB connection to get the 
pipe configuration ? Because this could be a problem for some systems, 
(like a light stateless proxy in front of other machines) because this 
will mean the requirement of loading a DB module.
If there is indeed the need for a database, than I suggest that we still 
allow cfg configuration , will the limitation that runtime changes 
aren't permanent and are lost in case of a restart.

Regarding the static indexing versus dynamic allocation of pipes, I was 
thinking that most setups only need a few pipes and that number  doesn't 
change very often. With this in mind I was thinking about combining the 
two approaches: start to a low number of pipes (16 for example which is 
basicaly an array on the stack or continuous allocation on the heap). In 
case of need of a 17th pipe double the capacity (allocate a 32  
continuous array on the heap ) and deep copy the old 16 pipes (something 
that std::vector in c++ does when we alter its capacity). This will add 
the advantage on using static indexing but still provide with the new 
functionality of a variable number of pipes.

What do you think?

Greetings,
Marius