Daniel-Constantin Mierla wrote: Hello, I am in no way a heavy user of ratelimit, only done a couple of tests using the TAILDROP algorithm. My primary interest was in extending the cfg framework from ser to k modules. I have dug around the documentation and the code so I can say I am familiar with some of the insights. I want to clear some documentation issues first. The ratelimit docs says the queue/pipe use the ipfw nomenclature. <quote> Packets belonging to the same flow are then passed to either of two different objects, which implement the traffic regulation: _pipe_ A pipe emulates a link with given bandwidth, propagation delay, queue size and packet loss rate. Packets are queued in front of the pipe as they come out from the classifier, and then transferred to the pipe according to the pipe's parameters. _queue_ A queue is an abstraction used to implement the WF2Q+ (Worst-case Fair Weighted Fair Queue-ing) Queueing) ing) policy, which is an efficient variant of the WFQ policy. The queue associates a _weight_ and a reference pipe to each flow, and then all backlogged (i.e., with packets queued) flows linked to the same pipe share the pipe's bandwidth pro-portionally proportionally portionally to their weights. Note that weights are not priorities; a flow with a lower weight is still guaranteed to get its fraction of the bandwidth even if a flow with a higher weight is permanently backlogged. In practice, _pipes_ can be used to set hard limits to the bandwidth that a flow can use, whereas _queues_ can be used to determine how different flow share the available bandwidth. The _pipe_ and _queue_ configuration commands are the following: </quote> I might add the following nice to have features(provided by implementing and extending queues): - Matching of packets to a specific queue should be done by via regexp, not only method (ratelimit.c find_queue() method). If you remove queues, then matching to a specific pipe... - Add support for weighted queue eg. Specify the same pipe for invite and register but allow a 25%-75% priorities. I yet don't know if we can have several queues assigned per pipe. As a comment, ATM I guess queues are only used to match request to pipes(Say REGISTER and SUBSCRIBE requests go to pipe 1, INVITEs to pipe 2) - Also it would be nice to modify rates(bandwidth in ipfw terminology) at runtime. AFAIK one can only modify algorithm parameters, not the rate. I am looking into it. Hm, I would suggest keeping compatibility between the new module and the old and mark the old as obsolete. The alg section is just a few hundred lines, and the queue functionality isn't yet that advanced(no weights and such), and could be easily duplicated and extended into the new. Any ideas?! Cheers, Marius _______________________________________________ Kamailio (OpenSER) - Users mailing list Users(a)lists.kamailio.org http://lists.kamailio.org/cgi-bin/mailman/listinfo/users http://lists.openser-project.org/cgi-bin/mailman/listinfo/users

Hello, On 1/22/10 3:31 PM, Ovidiu Sas wrote: 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 Ovidiu, i did not reviewed the code yet, but some people also like to run their balancers without a database to avoid this additional complexity.

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.

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.

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