[OpenSIPS-Devel] Avoiding creating outgoing TCP connections for NOTIFY requests

Bogdan-Andrei Iancu bogdan at opensips.org
Fri Oct 12 16:35:54 CEST 2012


Hi Saúl,

Well, looking at this particular case (presence), we have 2 options:
     1) simplify everything and gave internally the 
tcp_no_new_conn_bflag set when firing a NOTIFY.
     2) remember (in the watcher structure) if the subscription was from 
behind a NAT and if so, internally set the tcp_no_new_conn_bflag set 
when firing a NOTIFY for that subscription.

Ideally, in both cases, if tcp_send() fails, we should terminate the 
subscription, IMHO.


Now, in long term, I was brainstorming with Vlad to try to get rid of 
this blocking TCP stuff (generally in openspis). The idea we came up 
with is (if the write/connect will block) to move the operation in the 
TCP main process in the epoll (to wait to write indication) - that will 
mean to move the buffer in shm, and to attach it to the TCP conn for 
waiting; of course, the TCP conn states will have to be re-worked to 
make place for the waiting states.
This is no an async operation, we simply move it in a different process 
for waiting - in such a case, we will not be able to tell if the op was 
successful or not - the process which wants to do the TCP write will 
simply continue with success even if the actual write is still ongoing 
in a different process. There is work around for this as we cannot 
suspend the execution of SIP msg in opensips (there are no context) - 
this something that only 2.0 can do.

What do you thing of the above idea ? :)

Regards,

Bogdan-Andrei Iancu
OpenSIPS Founder and Developer
http://www.opensips-solutions.com


On 10/08/2012 08:06 PM, Saúl Ibarra Corretgé wrote:
> Hi all,
>
> In order to avoid creating an outgoing TCP connection which would block needlessly we have the ability to use tcp_no_new_conn_bflag. When looking up the location for a user all flags will be loaded, so if we specified the said flag when the user was registered a new connection will not be attempted if there is no connection.
>
> However AFAIK this doesn't apply to NOTIFY requests generated by OpenSIPS when using presence. Scenario is simple: user subscribes using TCP, her connection breaks, someone sends a PUBLISH. OpenSIPS will try to open a connection to deliver the NOTIFY. This is what I'd like to avoid.
>
> First thing that comes to my mind is reusing the idea with tcp_no_new_conn_bflag, so if a user sets if before calling handle_subscribe, in-dialog NOTIFY requests would not attempt to create the connection.
>
> Thoughts, proposals, patches are welcome :-)
>
>
> Regards,
>
> --
> Saúl Ibarra Corretgé
> AG Projects
>
>
>
>
> _______________________________________________
> Devel mailing list
> Devel at lists.opensips.org
> http://lists.opensips.org/cgi-bin/mailman/listinfo/devel
>



More information about the Devel mailing list