RE: [reSIProcate] TCP Behavior - on Windows at least...

["Derek MacDonald" <derek@xxxxxxxx>]

We ran into this bug in ares, albeit for UDP. Windows sometimes gives a
false positive from select.  The approach is to do an FD_CLR when
WSAEWOULDBLOCK is returned. See line 289 pf ares_process for an example.

--Derek

CONFIDENTIALITY NOTICE

This email and any files transmitted with it contains proprietary
information and, unless expressly stated otherwise, all contents and
attachments are confidential. This email is intended for the addressee(s)
only and access by anyone else is unauthorized. If you are not an addressee,
any disclosure, distribution, printing or copying of the contents of this
email or its attachments, or any action taken in reliance on it, is
unauthorized and may be unlawful. If you are not an addressee, please inform
the sender immediately and then delete this email and any copies of it.
Thank you for your co-operation.

> -----Original Message-----
> From: resiprocate-devel-bounces@xxxxxxxxxxxxxxxxxxx [mailto:resiprocate-
> devel-bounces@xxxxxxxxxxxxxxxxxxx] On Behalf Of Scott Godin
> Sent: Thursday, April 21, 2005 10:19 AM
> To: 'Alan Hawrylyshen'; Scott Godin
> Cc: resiprocate-devel@xxxxxxxxxxxxxxxxxxx
> Subject: RE: [reSIProcate] TCP Behavior - on Windows at least...
> 
> Thanks for responding Alan!
> 
> I'm using SVN head.  I can see resip is closing via Ethereal (ACK-FIN).
> After digging some more, I can also see in the resip logs....
> 
> The problem is triggered in the following code:
> void
> TcpBaseTransport::processSomeReads(FdSet& fdset)
> {
>    Connection* currConnection = mConnectionManager.getNextRead();
>    if (currConnection)
>    {
>       if ( fdset.readyToRead(currConnection->getSocket()) ||
>            currConnection->hasDataToRead() )
>       {
>          DebugLog (<< "TcpBaseTransport::processSomeReads() " <<
> *currConnection);
>          fdset.clear(currConnection->getSocket());
> 
>          int bytesRead = currConnection->read(mStateMachineFifo);
>          DebugLog (<< "TcpBaseTransport::processSomeReads() "
>                    << *currConnection << " read=" << bytesRead);
>          if (bytesRead < 0)
>          {
>             DebugLog (<< "Closing connection bytesRead=" << bytesRead);
>             delete currConnection;
>          }
>       }
> ...
> 
> For some reason fdset.readyToReady is returning TRUE, but then
> currConnection->read is returning WSAWOULDBLOCK.  Therefore resip tears
> down
> the socket connection.  I suspect the problem is Windows related.  Are you
> using windows at all?
> 
> I'm still digging (trying to understand why readyToRead is returning
> true),
> so any help or suggestions would be appreciated.
> 
> Thanks,
> 
> Scott
> 
> 
> -----Original Message-----
> From: Alan Hawrylyshen [mailto:alan@xxxxxxxxxx]
> Sent: Thursday, April 21, 2005 1:12 PM
> To: Scott Godin
> Subject: Re: [reSIProcate] TCP Behavior - on Windows at least...
> 
> 
> On Apr 21, 2005, at 09.36, Scott Godin wrote:
> 
> > I've been noticing the following behavior when using TCP transport (on
> > Windows):
> >
> >     1       Resip disconnects socket connections immediately after
> receiving
> > SIP requests from the far end.
> >     2       For UAC Invites - resip closes the socket after receiving
> the 200
> > and reopens a new one for sending the ACK.
> >     3       For UAS Invites - resip does not close the socket after
> sending a
> > 200, but waits for the ACK before closing.
> >
> > For 1 - is this correct?
> > For 2 and 3 - which of these are correct?
> > Should resip be closing socket connections that it did not create?
> >
> > Any plans to implement connection re-use?
> >
> > Thanks,
> >
> > Scott
> > ___
> 
> We aren't seeing this. What repository revision is showing you this,
> and can you see the TCP-level RST / FIN bits?
> IOW -- are you SURE resip is doing the closing?
> A
> 
> a l a n a t j a s o m i d o t c o m
> _______________________________________________
> resiprocate-devel mailing list
> resiprocate-devel@xxxxxxxxxxxxxxxxxxx
> https://list.sipfoundry.org/mailman/listinfo/resiprocate-devel