[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