25 Jan
2010
25 Jan
'10
11:57 a.m.
Hello,
On 1/25/10 10:45 AM, marius zbihlei wrote:
Daniel-Constantin Mierla wrote:
the changes are related to the storage engine (db and in memory) by
allowing string names and dynamic add/remove pipes.
Hello,
On 1/22/10 3:31 PM, Ovidiu Sas wrote:
Hello,
I saw the pipelimit commit, and I am going to have a look to better
understand the design. 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
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(a)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/