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

[Ovidiu Sas]

Hello,

I'm in favor of keeping this module as a db only module.  Combining
both init methods (param and db config) is messy due to the current
module initialization (the shm mem is not available during the param
parsing).
For small/embedded systems db_text is always a viable alternative.

In the future, the ratelimit module should become obsolete and only
pipelimit should be maintained.
Also, I'm in favor of keeping the new module as simple as possible and
perform any fancy operations in the config file (like regex to pv via
textops).

Regards,
Ovidiu Sas

On Mon, Jan 25, 2010 at 4:57 AM, Daniel-Constantin Mierla
<miconda at gmail.com> wrote:
> Hello,
>
> On 1/25/10 10:45 AM, marius zbihlei wrote:
>>
>> 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 changes are related to the storage engine (db and in memory) by allowing
> string names and dynamic add/remove pipes.
>>
>>  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 ?
>
> yes. That's why I said the old module should be kept and maybe export pipe
> algo in a lib ir from module.
>
> I was thinking at some point more or less to your idea, to combine. But the
> complexity introduced to adapt from one to another does not pay the effort
> imo when comparing with having two modules clear targeting different sizes.
>
> Most of the cases are as you say, but there are cases when the limit wants
> to be for each destination or source ip, and that can be controlled via
> other meanings, like dispatcher, lcr, etc... new ips can appear/disappear
> dynamically. Having static array with fixed indexing is not convenient.
>
> I uploaded the module so people can discuss based on it. The sql to create
> the table is in one of the c files at the top.
>
> Cheers,
> Daniel
>>
>> 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
>>
>>
>>
>>
>> _______________________________________________
>> 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
> * http://www.asipto.com/
>
>
> _______________________________________________
> 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
>