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

[Ravitez Ravi]

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> 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 Solutionswww.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 listUsers at lists.opensips.orghttp://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/20170509/c9444116/attachment-0001.html>