reSIProcate

Mailing Lists

Source Code

Google Search:



< Previous by Date Date Index Next by Date >
< Previous in Thread Thread Index Next in Thread >

Re: [reSIProcate-users] Unexpected TCP connection termination disturbing call setup

I'm not sure why you are still seeing this with 1.8.14.  Looking at the following log statements:

11/10/2013 21:14:10 [Debug] RESIP | 13376 | SipStack.cxx:571 | SEND: SipReq:  NOTIFY 5902@10.0.1.18:5060 tid=75234f2f0f140f5f cseq=8 NOTIFY contact=5901 / 8 from(tu)
11/10/2013 21:14:10 [Info] RESIP:TRANSPORT | 8808 | TcpConnection.cxx:97 | Failed write on 3256 Unknown error
11/10/2013 21:14:10 [Debug] RESIP:TRANSPORT | 8808 | Transport.cxx:156 | Would Block 
11/10/2013 21:14:10 [Info] RESIP:TRANSPORT | 8808 | Connection.cxx:168 | Write failed on socket: 3256, closing connection

From Transport.cxx:156 - we know you are getting back WSAEWOULDBLOCK - if you look at the code in Connection.cxx near line 168 - it should be skipping the closing connection "if" statement due to EWOULDBLOCK being equal to WSAEWOULDBLOCK.

   int nBytes = write(data.data() + mSendPos,int(data.size() - mSendPos));
   if (nBytes < 0)
   {  
      if (errno != EAGAIN && errno != EWOULDBLOCK) // Treat EGAIN and EWOULDBLOCK as the same: http://stackoverflow.com/questions/7003234/which-systems-define-eagain-and-ewouldblock-as-different-values
      {
         //fail(data.transactionId);
         InfoLog(<< "Write failed on socket: " << this->getSocket() << ", closing connection");
         return -1;
      }
      else
      {
         return 0;
      }
   }

Can you place some debug log statements around this code and see if you can understand why it is still going into the block that closes the connection?

Scott


On Fri, Oct 11, 2013 at 10:00 PM, Julio Cesar Esteves Cabezas <jcabezas@xxxxxxxxxxxxx> wrote:
Hello,

    I built our app with the latest reSIProcate 1.8.14 and tested it
(instead of original 1.8.5). Unfortunately the problem of dropped TCP
connections STILL HAPPENS without noticeable change.
    In the attached zipped _SipEngine_DroppedConnection.log we can see
failure events around 21:14:10, lines 7362~7364, 9428~9430, 9966~9968,
11740.

    Also in a quick overview I could not find in TcpConnection.cxx,
TcpTransport.cxx, Transport.cxx, TcpBaseTransport.cxx changes that suggest
some effective new handling of that issue.

    The tests suggest that the rapid sucessive emission of many long SIP
NOTIFYs is probably overloading internal buffers capacity or other essential
resource.
    It looks as if the default settings for TCP protocol that are in use
aren't tuned to such a regime of bursty high bandwidth usage.

    What can be done on that issue ?

    I can provide a corresponding Wireshark capture if wanted.

Many thanks,
Julio.


_______________________________________________
resiprocate-users mailing list
resiprocate-users@xxxxxxxxxxxxxxx
List Archive: http://list.resiprocate.org/archive/resiprocate-users/