[SR-Dev] [Serdev] CVS:commitlog: sip_router/modules/tm t_cancel.c t_fwd.c t_reply.c t_reply.h t_suspend.c t_suspend.h tm.c tm_load.c tm_load.h

Andrei Pelinescu-Onciul andrei at iptel.org
Thu Dec 11 22:34:10 CET 2008

On Dec 09, 2008 at 12:07, Klaus Darilion <klaus.mailinglists at pernau.at> wrote:
> Andrei Pelinescu-Onciul schrieb:
> >[crossposting since this is of general interest]
> >
> >On Nov 12, 2008 at 00:30, Klaus Darilion <klaus.mailinglists at pernau.at> 
> >wrote:
> >>Can this also be used for DNS lookups and TCP/TLS connection setup?
> >
> >Yes for DNS (see above) and in general for any route-level async 
> >processing
> >involving tm (e.g. lookup some part of the message in a slow DB and 
> >execute automatically another route when the DB responds).
> >
> >It cannot be used for TCP/TLS, but it's not needed anyway. In ser TCP
> >connection setup and TCP send is already asynchronous, at least if
> >you have tcp_buf_write=yes in ser.cfg (I agree it's not a very well
> >chosen name :-)). TLS does not support it yet, so if you use TLS
> Hi Andrei!
> I wonder what happen if the asynchronous sending fails (e.g. TCP 
> connection is lost). Will it jump to failure route (for requests)?

It will time out and then jump into the failure route (it doesn't jump
directly on async send failure, it will wait for the transaction timeout).

> What happens if the sending of the response (e.g. 200 ok) fails? Will acc 
> module account the failed 200 ok?

No, not directly (it has to look for the ACK). On tcp in general is not
possible to say what packet made it to the other side when a connection
is suddenly closed, while still having data in the socket send buffers.
With the async send we could make it a little better and detect _some_
packets that we know for sure we did not send (and callback tm and
fallback or execute the failure route for them), but we cannot tell
anything about all the stuff in the socket send buffers (64k+).
I think this would help only for the async. connect part (where we don't
have any kernel buffering), but for already opened connection that close
due to an error it won't help much.


More information about the sr-dev mailing list