On Fri, 2010-01-08 at 09:41 +0100, Daniel Stenberg wrote:
> On Thu, 7 Jan 2010, Chris Conroy wrote:
>
> > I've made a lot of progress on the RTSP work I mentioned a few months ago
> > (other projects and the holidays got in the way until recently...)
> >
> > But, I've hit an issue which has me stuck at the moment. Minus unit tests,
> > once I get past this issue I should have a patch ready for review in very
> > short order.
>
> Cool, I'm looking forward to that! Are you in sync with CVS or are you working
> against a fixed release?
Right now, I'm working against 7.19.7, but I could pretty easily upgrade
to the latest CVS if that is your preference.

>
> > The basic code flow is that to handle interleaved RTP, I have a kind of
> > no-op request which doesn't send anything to the server but simply reads any
> > pending RTP data since this data comes outside of the normal
> > request->response flow.
> >
> > The problem I've encountered is that, seemingly randomly, going into this
> > code path cause curl to throw up "Connection #x seems to be dead!" when it
> > runs ConnectionExists.
> >
> > My best guess as to the cause is that there is some nuance I am missing
> > regarding readwrite_data() which says the loop there should read everything
> > until it would block. In this flow, I'm returning earlier than that in order
> > to give the application a chance to run. Looking at the packet trace, it
> > seems that the client (curl) side of the connection is tossing out a RST for
> > no good reason.
>
> I'm not sure I understand the scenario nor how curl can cause a RST since it
> has no way of doing that!

See my response below, but I think that this makes sense with your
explanation since it results in a Curl_disconnect() call.
>
> A wrong "Connection #x seems to be dead" message would easily happen if you
> prematurely return with incoming data pending. The function that is later used
> to find a connection to re-use will then check if the socket is readable,
> which implies that the connection has died in the mean time and then it'll say
> something like that. However, if you left the connection before it was
> properly drained it can thus end up be readable at that point without having
> been closed and then the code will wrongly think it died when it merely had
> traffic...

Well, that's good news because it means we know the source of the issue.
However, letting it read all incoming data is almost definitely not what
we want to happen here. Once the server starts sending interleaved RTP
data, it will do so until the stream is over. However, the application
will need the ability to issue other commands over the same connection
(e.g. PAUSE) while this is happening. Let me know if you have any
thoughts on how to work around this problem.

--Chris

-------------------------------------------------------------------
List admin: http://cool.haxx.se/list/listinfo/curl-library
Etiquette: http://curl.haxx.se/mail/etiquette.html
Received on 2010-01-08