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

[Adam Roach]

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://list.resiprocate.org/pipermail/resiprocate-devel/attachments/20091015/6a20668b/attachment.htm>