[Live-devel] RTSPServer disconnects client session in incomingRequestHandler1 [Possible patch]

[Ralf Globisch]

Hi Ross, 

One of my colleagues Louis Joubert found that the socket descriptors never got deleted. 
I've included his mail below. He found the difference between Windows and Linux socket implementations: 
On Windows and it seems like the accept() call returns different socket descriptors/handles 
each time while on Linux the same handles get reused.

Further debugging showed that in RTPInterface::removeStreamSocket deletes RTPInterface::fTCPStreams. 
This causes the deregisterRTPInterface to never get called by stopNetworkReading since fTCPStreams is NULL.

One quick fix we tried is to duplicate the deregistration code from stopNetworkReading in removeStreamSocket:
Since the RTSPClientSession is being deleted it should be safe to deregister the stream socket at this point?
We have attached this as a patch though we're not sure whether there are any other (unintended) side-effects.

In our tests the subsequent TCP connections are now handled by the correct handler.

Regards,
Ralf

>Hey Ralf
>
>Was looking at the live555 stuff, and this is what I can see is happening
>... dunno if it is worth anything?
>
>For every TCP connection a SocketDescriptor is created, which contains a
>hastable of subchannel stuff
>
>there is also a global hashtable of open SocketDescriptors, keyed on the
>socket descriptor returned from the accept() call
>
>ok. so on the initial TCP connection, a SocketDescriptor is created, and in
>SocketDescriptor::registerRTPInterface somewhere
>tcpHandler is assigned as a handler if isFirstRegistration is true,
>
>
>The problem is ... when the TCP connection is terminated, the above
>SocketDescriptor never gets deleted (as far is i can tell?)
>
>So, on subsequent TCP connects, the old SocketDescriptor is reused (which
>already has subchannels assigned, and therefore isFirstRegistration is
>false), and the tcpHandler thingy doesn't get set, resulting in the wrong
>handlers being called
>
>however, if you make the second TCP connection before that destructor thing
>of yours gets called (printed out in the DEBUG_RR thing), the previous
>socket is still active, accept() will return a new socket descriptor, a new
>SocketDescriptor gets created, the tcpHandler gets assigned and things work.
>But once any TCP connection gets terminated, you will have stale
>SocketDescriptors hanging around and things will break.
>
>Dunno why it would work in Windows ... maybe Windows doesn't reuse socket
>descriptor values even when the sockets were closed? No idea.
>
>In any case ... SocketDescriptors should get deleted somewhere?





-- 
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.

-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: RTPInterface.patch
URL: <http://lists.live555.com/pipermail/live-devel/attachments/20081103/9bd22586/attachment.ksh>