[SR-Users] TCP stack is not doing load distribution among children for SIP
Daniel-Constantin Mierla
miconda at gmail.com
Wed Mar 8 08:56:32 CET 2017
On 08/03/2017 08:01, Juha Heinanen wrote:
> Daniel-Constantin Mierla writes:
>
>>> So, for example, if k2 is a presence server and k1 is forwarding
>>> subscribes/publish requests to it, only one process at k2 would be
>>> processing them since the tcp connection between k1 and k2 is reused?
>>>
>> Those were the observations described by the one opening this thread and
>> then I responded with why I think it happens so, but as I wrote, I
>> haven't really checked the source code yet.
> If that is true, then K tcp implementation is really broken. Why can't
> tcp manager distribute the requests that come over a shared single
> connection to the workers?
Well, if you think this (my assumption) is broken, then your approach is
also broken, because then you have one single sip tcp reader (the tcp
manager), so you just shift the problem to another place.
Tcp manager process is just dealing with tcp connections only, not doing
any sip stuff.
This situation is exposed only when having a trunk between two servers,
otherwise when phones connect via tcp/tls, there is a connection for
each. I already exposed my assumption of keeping the connection, as the
sip tcp worker sends back some reply in most of the cases (auth
challenge, trying...).
So, I wouldn't call the current implementation like broken at all, I
know deployments with many hundred thousands of active tcp/tls
connections, working for many years without issues. This is just someone
reported a case that is not handled as one expects.
Besides writing some code to do an enhancement for this trunking case,
another solution that came in my mind using current version is to
leverage the async layer via the config file: if the request is sent
from the other server, then suspend the transaction and resume it in an
another processes (rtimer or maybe async workers). I already exposed two
other solutions with using different ports or closing connections after
sending out.
Cheers,
Daniel
--
Daniel-Constantin Mierla
www.twitter.com/miconda -- www.linkedin.com/in/miconda
Kamailio Advanced Training - Mar 6-8 (Europe) and Mar 20-22 (USA) - www.asipto.com
Kamailio World Conference - May 8-10, 2017 - www.kamailioworld.com
More information about the sr-users
mailing list