24 Jun
2020
24 Jun
'20
5:42 p.m.
I never said there was a bug. I don't think it is a bug. For me a bug is something
wrong in the code, so the application does not behave as it is expected. In this case the
code is right. It does what it is expected to do. Problem is, I think the expected
behavior is a bad behavior. Maybe the original developer did not think carefully about
this. There is very little use on real life scenarios, unless all destinations have plenty
of free resources, so they can process double or triple load. Maybe the guy would say
"yeah, it's a good improvement! Let's do it in a backward compatible
way!"
Please, take a look at issue #2361. if, instead of Calls, those were CAPS, so every
destination processes 1000CAPS. What if those nodes can't process 2000 CAPS? For
instance they are capable of processing 1500CAPS. When one destination fails, the next
will receive 2000 CAPS. But it can't. Currently Kamailio can't solve that
scenario. Wouldn't it be better that every destination now processes 1200 CAPS?
That was the point I wanted to discuss. A better distribution. If everything is normal.
Every destination receives, more or less, same amount of calls (it's just hash, not
fair distribution). If some destinations fail, the calls they were supposed to receive are
better distributed over the remaining destinations, but respecting the hash : same hash,
same destination.
If servers active change between INVITE and other messages, I don't think there is a
stateless way to solve it. The current implementation also fails. First, for what I saw in
the code, the list contains all destinations, not just those active. Once hashid is
obtained, modulo #total destination is applied, and then state of destination is checked.
If it's not active, next is selected. if next is active, INVITE is sent to it.
What if, when CANCEL is received, the original destination was again active? Hashid is
obtained, modulo #total, server is active, CANCEL is sent to wrong server. As I said, I
don't think there is a fully stateless way to solve it. kamailio should memorize
original destination, or something complex, beyond the scope of a simple hash.
I did care about continuing service. OK, if a server goes down and later goes up, it will
cause some calls to fail, with current implementation and also mine. But, service should
continue. It would be a high availability platform, that can continue providing service to
new calls, but failing on transient ones. And with a better distribution.
I did not want to add a new feature. I wanted to improve existing ones. The hash
algorithms can be improved, as any part of the code may eventually be improved.
_Now, if I wanted to implement it your way, in a new algorithm, I have no idea about how
could I get inside function ds_manage_routes() the value to be used as a hash. You said,
for instance, $var(dshash) = $ci . How can I get the content of dshash inside that
function?_
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/kamailio/kamailio/pull/2363#issuecomment-649088481