Re: [reSIProcate-users] Transmission to broken TCP connection

[Adam Roach <adam@xxxxxxxxxxx>]

On 10/15/09 03:27, Oct 15, Mats Behre wrote:

So, it seems that when the message is sent the read side detects that the connection is down (with a code that
is unrecognised by TCP, but decoded as WSAECONNRESET in Transport::error), but it doesn't appear as if our
application is notified.
This may be kind of a grey area; RFC 3261 (18.4) specifies that if the result of sending a request
is a connection failure, the transport user SHOULD be informed, and 17.1.4 says the the TU SHOULD
be notified. I believe our application takes the role of the TU, and is responsible for further actions.
Is this situation covered by "the result is a connection failure"? I think it can be argued that it is.

The problem from our point of view is that it takes a long time (transaction timeout) before the application
finds out about the failure. Is there anything we can do to avoid this?

[I'm copying the devel list on this, as it has recently come up there as well]

This is a known shortcoming of the current TCP transport design. Ideally, a socket failure on write would cause the TCP transport to re-initiate a connection and re-attempt sending the message that failed (with care not to get into a loop of try/fail/try/fail, ad infinitum). If the second attempt fails, the transport should then inform the TU. I haven't done any analysis to see how much work this would take, but it sounds like a fairly easy fix -- unfortunately, I don't have any cycles to work on it myself.

If you'd like to dig into things and propose a patch, I would start with resip/stack/TcpTransport.{cxx,hxx} and resip/stack/TcpBaseTransport.{cxx,hxx}.

/a