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
_______________________________________________
Kamailio (SER) - Development Mailing List
sr-dev@lists.kamailio.org
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-dev
