[sr-dev] About TCP connection failure (reject and timeout)

[Iñaki Baz Castillo]

2011/6/23 Andrei Pelinescu-Onciul <andrei at iptel.org>:
> Yes, it's a known limitation. Basically when async it's own, tm has no
> way of knowing that a connect() has failed and would have to rely on sip
> timeout.
> Of course these could be changed, but it would have both performance and
> memory usage impact and it would be very hard to integrate with tls.
> I would rather not do it in the near future.

Ok, I understand. It would be great to have it however.

In the other side, this has an unexpected advantage:

It unifies both behaviours of UDP and TCP/TLS. In sync mode, if a TCP
connection fails t_relay returns an error and doesn't execute
on_failure_route block (I still this is a bug in the design as a TCP
connection error should trigger a local 503 so on_failure_route should
be called with such 503 as winning reply). Anyhow, in async mode, due
to the explained limitation, a TCP connection error would generate a
local timeout so on_failure_route would be called with 408 as winning
reply. This allows unifying code for UDP and TCP in the script.




> The tcp_connect_timeout refers to how long the tcp connect will be
> attempted, but it's not linked to tm. The value is not 100% exact,
> the tcp timers are executed on a best effort basis, at most at 5s
> intervals and at minimum 1/16 seconds, so you should expect a 5s error
> If it's too much for you, change TCP_MAIN_SELECT_TIMEOUT and
> TCP_CHILD_SELECT_TIMEOUT in tcp_conn.h (btw. we don't use select()
> anymore, the names where not updated when we switched to
> epoll/kqueue/dev_poll).

Thanks, I don't need it to be less than 5 seconds, neither I care it
as anyway I must wait fr_timer seconds :)


Thanks a lot.

-- 
Iñaki Baz Castillo
<ibc at aliax.net>