Re: [reSIProcate-users] Controlling TCP connection reuse
Right now the stack will not automatically close any TCP connections, unless it get's an error sending or receiving, or the OS has run out of TCP socket descriptors (TcpBaseTransport.cxx line 153). Dead TCP connections are not normally detected until you try to send data on them. Using the KeepAliveManager will help to cleanup dead connections, since it will ensure there is some data sent on each connection periodically. However on some OS's, it can still take up to 2 mins to discover the connection is dead, after attempting to send data on it.
Closing the TCP connection after each transaction does not sound like a good way to go, since it will be difficult to ensure that each TCP connection is only used for one transaction at a time, TCP connections are reasonably expensive, and this suggestion appears to go against RFC3261:
o In RFC 2543, closure of a TCP connection was made equivalent to a
CANCEL. This was nearly impossible to implement (and wrong) for
TCP connections between proxies. This has been eliminated, so
that there is no coupling between TCP connection state and SIP
processing.
I'm not sure that there is a better/faster way to recover from dead TCP connections. Does anyone else have any ideas?
Scott
On Fri, May 15, 2009 at 11:16 AM, Paul Kurmas
<pkurmas@xxxxxxxxxxxxx> wrote:
I'm chasing an issue with stale connections to a remote endpoint that
was shutdown incorrectly. The TCP socket remains open, and there are no
keep-alives (either TCP or application (via DUM's KeepAliveManager).
When the remote endpoint restarts, the 1st INVITE is sent over that
stale connection, and the remote endpoint stack returns a TCP RST. On
the local endpoint there is no immediate reaction -- the application
stalls until the INVITE expires. The next request works fine because a
new connection must be opened.
I have activated DUM's KeepAliveManager and it does seem to clear the
connection after some time. That's good, but I'd prefer something more
responsive. It seems to me the best solution is to close the connection
after a much shorter period of time. This could be an immediate closure
of the TCP connection after a transaction is complete or a pathetically
low value for the aging of the cached connections.
I'd appreciate any feedback you could provide. By the way, we're
running Resiprocate v1.3.4 at this time.
PK
_______________________________________________
resiprocate-users mailing list
resiprocate-users@xxxxxxxxxxxxxxx
List Archive: http://list.resiprocate.org/archive/resiprocate-users/