[OpenSIPS-Users] REG::Opensips V1.11.5 & V1.11.10 Duplicate TCP Conections

Răzvan Crainea razvan at opensips.org
Mon May 15 05:36:31 EDT 2017


Hi, Ravitez!

As I said, unfortunately there is no way to prevent OpenSIPS from doing 
this.
The only thing I can think of is to somehow "delay" the connect by 
randomly delay processing. I know this is not the best solution, but 
unfortunately there's nothing to do with the current design.

Best regards,

Răzvan Crainea
OpenSIPS Solutions
www.opensips-solutions.com

On 05/12/2017 01:55 AM, Ravitez Ravi wrote:
> Hello Razvan,
>                     Good Day,
>                     Would like to bring up that if children(workes) 
> try to create TCP connections without a locking mechanism we may hit 
> TCP connection limit and  not process or handle valid requests
>
> eg :
> tcp_max_connections=10;
> tcp_connection_lifetime=43200;
> tcp_children=32
>                   Considering the above configuration with the 
> existing framework we can use up all 10 connections and then reject 
> new connections.
>                   Please advise.Thank you :)
>
>
> Regard,
> Ravitez.D
>
>
> On Tue, May 9, 2017 at 10:20 AM, Ravitez Ravi 
> <ravitez.dondeti at gmail.com <mailto:ravitez.dondeti at gmail.com>> wrote:
>
>     Hello Razvan,
>                        God Day,
>                        Thank you for the update,it seems that though
>     we create multiple TCP connections opensips uses only one tcp
>     connection to send the data out.
>                        should a child be locking the tcp connection
>     mechanism? while creating a new tcp connection as we will be
>     overwriting the tcpconn_aliases_has to the
>                        latest/recent fd.
>
>>      I believe here's the root cause :
>>         - When a child tries to find a connection to the destination
>>     it calls _tcpconn_find() (assuming we are using ip and not id)
>>     system checks _/*tcpconn_aliases_hash */_for the connection info.
>>     */this map is maintained by the parent process and each child
>>     lock its while reaing tcpconn_get().in order to simulate the
>>     scenario lets assume a->parent->state is BAD this method/*
>>     */      will return null and so the child tries to create a new
>>     connections,assuming there's a second child trying to find the
>>     same connections and goes through the same process/*
>>
>>       - */Now each child thinks there's no connection to the
>>     destination and calls tcpconn_connect() this will create a socket
>>     to the destination and passes over the fd to the /*
>>     */    main process to update the has map./*
>>
>>       - */Not sure if tcp_connect() should have locking mechanism as
>>     in tcpconn_get()./*
>                Thank you :)
>
>     Regards,
>     Ravitez.D
>
>     On Mon, May 8, 2017 at 10:48 AM, Răzvan Crainea
>     <razvan at opensips.org <mailto:razvan at opensips.org>> wrote:
>
>         Hi, Ravitez!
>
>         You are right - if opensips gets multiple messages in parallel
>         that need to get to a single destination, each process will
>         open a different connection to that destination. However, all
>         sequential messages will use a single TCP connection.
>         Synchronizing all the TCP actions to ensure you will have a
>         single connection might be a bit overkill in terms of performance.
>
>         May I ask if this is a problem for you? Can you detail a bit why?
>
>         Best regards,
>
>         Răzvan Crainea
>         OpenSIPS Solutions
>         www.opensips-solutions.com <http://www.opensips-solutions.com>
>
>         On 05/04/2017 04:11 PM, Ravitez Ravi wrote:
>>         Hi All,
>>                 Good Day,
>>                 I have been seeing opensips creating
>>         mutiple(duplicate) TCP connections to the same destination if
>>         hit with heavy call load.
>>
>>         *What do i mean?*
>>         opensips ip : 10.10.10.1
>>         Destination  : 10.10.10.2
>>         Tcp Children : 32
>>             Ideally opensips will create only one tcp connections and
>>         reuses it,if there's a heavy call load i see there are
>>         several tcp connections which are created to the same
>>         destination.
>>             I believe here's the root cause :
>>             - When a child tries to find a connection to the
>>         destination it calls _tcpconn_find() (assuming we are using
>>         ip and not id) system checks tcpconn_aliases_hash for the
>>         connection info.
>>               this map is maintained by the parent process and each
>>         child lock its while reaing tcpconn_get().in order to
>>         simulate the scenario lets assume a->parent->state is BAD
>>         this method
>>               will return null and so the child tries to create a new
>>         connections,assuming there's a second child trying to find
>>         the same connections and goes through the same process
>>
>>           - Now each child thinks there's no connection to the
>>         destination and calls tcpconn_connect() this will create a
>>         socket to the destination and passes over the fd to the
>>             main process to update the has map.
>>
>>           - Not sure if tcp_connect() should have locking
>>         mechanism as in tcpconn_get().
>>
>>
>>
>>         Please correct me if my understanding is wrong,please share
>>         your thoughts.
>>         Thank you.
>>
>>
>>
>>         Regards,
>>         Ravitez.D
>>
>>
>>         _______________________________________________
>>         Users mailing list
>>         Users at lists.opensips.org <mailto:Users at lists.opensips.org>
>>         http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>>         <http://lists.opensips.org/cgi-bin/mailman/listinfo/users>
>
>
>         _______________________________________________
>         Users mailing list
>         Users at lists.opensips.org <mailto:Users at lists.opensips.org>
>         http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>         <http://lists.opensips.org/cgi-bin/mailman/listinfo/users>
>
>
>
>
>
> _______________________________________________
> Users mailing list
> Users at lists.opensips.org
> http://lists.opensips.org/cgi-bin/mailman/listinfo/users

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opensips.org/pipermail/users/attachments/20170515/c5848015/attachment-0001.html>


More information about the Users mailing list