Hi again,
Nice to read the comment from you. Yes it could be a case - but this race
condition will remain valid until I put some check on the insertion and
lock the resource if one user is using that table, I forgot what they say
in programming terms
What do you suggest i do to avoid this since I
Thanks Sir,
Doing a static or even a run-time mapping of same UID calls to destination
server is what I thought about this type of case almost an year ago.
What I am thinking is : create a table for UID/Destination Mapping; for a
unique UID see if there is any destination in that table. If it exis
Hello,
if you are using integer UID, I would suggest you use modulo operation
to select the destination address -- this will require config operations
only.
Another option you can map an UID to a dispatcher set id (e.g., via
mtree or htable) and then you can do the alg 8.
Cheers,
Daniel
O
Hi again,
yes my scenario is quiet simple. I've lots of users and groups of those
users are defined by UIDs, one UID means 70 users of one client whereas
other UID could've 3 users of another client.
So what I am trying to implement here is that calls from one same UID are
always routed to exactl
Hello,
that hash function is intended for hashing alpha-numeric usernames and
has a fair distribution for such cases.
I don't think is good for hashing numbers, at the end of a day, a number
is already like a hash code. You can use in the config file modulo
operation to select a particular d
Sorry for late reply: this wasn't very helpful. I think Hashing algo code
needs to get bit smarter. If there is any possibility can you please let me
know. !
On Mon, Jun 4, 2012 at 3:33 PM, Daniel-Constantin Mierla
wrote:
> To make the life easier to spot the hash code in such case, I just
> com
To make the life easier to spot the hash code in such case, I just
committed a small patch to print it for alg 7:
http://git.sip-router.org/cgi-bin/gitweb.cgi/sip-router/?a=commit;h=83a558fbad700198a8667ef01f756269d7e2c310
Should be easy to backport if other version is used.
Cheers,
Daniel
On
It's hard to say, most likely not. You find the used hash-function here:
841 unsigned int ds_get_hash(str *x, str *y)
http://git.sip-router.org/cgi-bin/gitweb.cgi?p=sip-router;a=blob;f=modules_k/dispatcher/dispatch.c;h=ae0c51b122d34e29b3474957a64b24ff492cfcd5;hb=HEAD
It was originally implemente
Thanks Sir,
Thats what I expected. Do you think this will change if I use only two
values with huge difference in each other, lets say {26000,29000} ?
Regards,
Sammy
On Mon, Jun 4, 2012 at 3:05 PM, Carsten Bock wrote:
> Hi,
>
> this functionality uses a generic "hash" function to generate an
>
Hi,
this functionality uses a generic "hash" function to generate an
Integer-Value of the PVAR and then reduces this to the number hosts in
your destination set.
If you have only using two different values of the PVAR and only two
hosts in the dispatcher list, it can likely happen, that the same h
Hi,
No, nothing at all. I haven't went too deep into debug logs but no internal
error was appearing. Everything was as calm as ever and I only get one
destination uri.
So maybe what I'm getting from your email is that , for this to work the
way I expect is to have more unique and random values in
Hello,
do you get any errors in the log?
Be aware that hash functions may return same code for different input
values. A hash function is guaranteed to return same code for same
input value, but there can be collisions of codes for different values.
Cheers,
Daniel
On 6/3/12 3:41 PM, SamyGo
Hello,
I'm having trouble using algorithm 7 in dispatcher module. Here is my
kamailio version. The problem is that despite multiple dispatcher entries
corresponding to one set all calls go only to only one destination.
[root@control1 ~]# kamailio -V
version: kamailio 3.2.3 (x86_64/linux) 59f87e
13 matches
Mail list logo
