[Live-devel] RTSPServer disconnects client session in incomingRequestHandler1 [Update]

[Ralf Globisch]

Hi Ross,

Managed to isolate the problem further, the RTSP Server session timeout triggers the RTCPInstance destructor (since the client has already disconnected). 
As soon as a RTCPInstance destructor has executed, the next RTSP client request is handled by the RTSP handler instead of the RTCP handler.

It does not make a difference where the client's connect from, whether from the same box as the server, other boxes, Windows and Linux clients.

The steps to replicate the problem have now been updated to:

1) Set the DynamicRTSPServer timeout to something short like 15 seconds.
2) a) add printf in ~RTCPInstance() (So you can see that the destructor has executed)
    b) add print f in RTSP request handler. (So you can see that the incorrect handler has been called)
    c)  Compile with DEBUG_RR (so you can see when the correct RTCP handler is called) and without DEBUG (which clogs the view)
3) Run the server
4) Connect an openRtsp client over tcp
5) Wait for a RTCP handler output (Everything is as should be)
5) Kill the client
6) Wait for the ~RTCPInstance printf on the server console (this will happen 15 seconds after the client was disconnected)
7) Connect a second openRTSP client (irrespective if from the same or from another machine)
8) See the RTSP handler output appear instead of the RTCP output.

I've traced the call from RTCPInstance::~RTCPInstance() to fRTCPInterface.stopNetworkReading() to envir().taskScheduler().turnOffBackgroundReadHandling(fGS->socketNum())
but I can't see anything wrong, I've added a whole wad of debug info but the flow of events always seems to be correct.

I've compared the addresses of the handler pointer that is passed through to turnOnBackgroundReadHandling for each RTCPInstance and they are the same so I can't understand how the other handler is being called.

Also, the only platform-dependent code is the FD_CLR macro in turnOffBackgroundReadHandling? But this code also gets used by the other socket connections?

Maybe now that it's narrowed down to a few lines of code, it will make sense to you?

Please let me know if you can replicate it or if you need any other info...

Regards,
Ralf



-- 
This message is subject to the CSIR's copyright terms and conditions, e-mail legal notice, and implemented Open Document Format (ODF) standard. 
The full disclaimer details can be found at http://www.csir.co.za/disclaimer.html.

This message has been scanned for viruses and dangerous content by MailScanner, 
and is believed to be clean.  MailScanner thanks Transtec Computers for their support.