RE: [reSIProcate] responses over TCP get lost when in the same pa cket
I'm not sure if you are experiencing the same problem I encountered with TCP
responses. In my case, I found that response message were not being sent
since the socket was not write-enabled.
I made the following change (which has not been applied to the repository)
to TcpBaseTransport.cxx at line 278:
273 else // have a connection
274 {
275 assert( conn->transport() );
276
277 conn->requestWrite(data);
==>278 fdset.setWrite(conn->getSocket());
279 }
Liz
> -----Original Message-----
> From: Bayart Frederik [mailto:Frederik.Bayart@xxxxxxxxxxx]
> Sent: Monday, January 24, 2005 3:30 AM
> To: reSIProcate List
> Subject: RE: [reSIProcate] responses over TCP get lost when
> in the same pa cket
>
>
> The message is read entirely but not added to the fifo. The
> source code is not very complicated. I will try to make some
> time this week to fix it.
>
> Frederik
> -----Original Message-----
> From: resiprocate-devel-bounces@xxxxxxxxxxxxxxxxxxx
> [mailto:resiprocate-devel-bounces@xxxxxxxxxxxxxxxxxxx]On
> Behalf Of Alan Hawrylyshen
> Sent: Friday, January 21, 2005 4:21 PM
> To: reSIProcate List
> Subject: Re: [reSIProcate] responses over TCP get lost when
> in the same packet
>
>
>
> On Jan 21, 2005, at 04:31, Jon Ringle wrote:
>
> > On Friday 21 January 2005 06:08 am, Bayart Frederik wrote:
> >> Hallo,
> >>
> >> I've have noticed following probleem when I'm sending messages over
> >> TCP :
> >> if 2 responses are arriving in the same packet, the second
> response
> >> is not
> >> passed to the transaction user. This happens in the function
> >> Connection::performRead. When 2 requests are arriving in the same
> >> packet,
> >> there is no problem.
> >>
> > <snip examples>
> >
> >>
> >> I didn't find any explanation for this in the rfc's.
> >
> > I believe this is addressed in RFC 3261 section 18.3,
> framing. If your
> > seeing this behaviour on tcp, then my take is that the
> problem is with
> > resiprocate. But this is just a guess. I am not completely familiar
> > with the
> > resiprocate stack yet, but the stack needs to keep track of
> partially
> > received messages so that when the rest of the message arrives a
> > complete
> > message can be made and passed to the transaction user. The
> framing of
> > SIP
> > messages is based on the Content-Length header.
> >
> > HTH,
> >
> > Jon
>
> Frederik and Jon;
>
> Yes, the Content-Length is important, presuming that it is working
> correctly, (and it sounds like it is, since the extra bytes
> message was
> seen) the problem is likely in the Connection class associated with
> TCP.
>
> DEBUG | ... | Check the Debug and Stack logs, I expect you
> will see: DEBUG | ... | Extra bytes after message: NNNN DEBUG
> | ... | 200 RAW DATA etc... DEBUG | ... | Connection::process
> setting source ... **
>
> Trouble is I suspect the like marked with ** is missing.
> This appears
> to be because just before the 'goto start' (!! :-) ) the
> mState of the
> connection is not set back to NewMessage. Check and see if applying
> this patch to Connection.cxx (r3821) fixes the problem you describe.
>
> I can take a look at this, but so can Jason, Derek or Jacob (at a
> working minimum) I think others are familiar with the message header
> scanner and connection FSMs too.
>
>
> Best wishes and hope this helps
>
> Alan
>
>
> Index: Connection.cxx
> ===================================================================
> --- Connection.cxx (revision 3821)
> +++ Connection.cxx (working copy)
> @@ -196,7 +196,8 @@
> mBuffer = newBuffer;
> mBufferPos = 0;
> mBufferSize = size;
> -
> + mState = NewMessage;
> +
> DebugLog (<< "Extra bytes after message: " <<
> overHang);
> DebugLog (<< Data(mBuffer, overHang));
>
>
>
> --
> 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
> _______________________________________________
> resiprocate-devel mailing list resiprocate-devel@xxxxxxxxxxxxxxxxxxx
> https://list.sipfoundry.org/mailman/listinfo/resiprocate-devel
>