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

[Saúl Ibarra Corretgé]

Hi Bogdan,

On Oct 12, 2012, at 4:35 PM, Bogdan-Andrei Iancu wrote:

> 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.

Not sure if I get this one. How/where would that flag be stored? You mean if the flag was set when handle_subscribe was called, for example?

>    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.
> 

This is more or less what I had in mind, so I'm all for it.

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

Right now IIRC OpenSIPS will only terminate the subscription if a 408 or 481 is received for a NOTIFY. Yes, we should terminate it if tcp_send fails. (More on this a bit below).

> 
> 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.

Makes sense :-) This way the worker process would be freed quicker even if TCP will later fail.

> 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.

If I understood correctly, since we lose the state, TCP would behave a bit like UDP, in that you don't know if something went wrong, until the transaction timeout kicks in and a local 408 is generated. Is my understanding correct? If it is, a huge +1 from me. Yes, it's a workaround, but it's the best thing we can do with the current design, and we really need TCP working properly soon.

iOS devices, for example, can't send an application to background and be woken up using UDP, they must use TCP or do manual polling, which kills the battery.

This is also really important for presence, in Blink we can't use UDP for subscriptions to presence because packets are so big they fragment and things just break. As for what you said about terminating subscriptions, if TCP now would behave more like UDP, if a NOTIFY can't be sent out then a local 408 would be generated, which (with the current code) would terminate the subscription, so looks like we may not even need to do anything there :-)

> 
> What do you thing of the above idea ? :)
> 

Love it :-) We already switched to TCP for the above stated reasons, so if you need testing let me know, I'll be more than happy to do so.


Regards,

--
Saúl Ibarra Corretgé
AG Projects