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.
*** ./New/RTPInterface.cpp 2008-11-03 10:40:17.000000000 +0200
--- ./Old/RTPInterface.cpp 2008-10-08 00:37:40.000000000 +0200
***************
*** 136,148 ****
streamsPtr = &((*streamsPtr)->fNext)) {
if ((*streamsPtr)->fStreamSocketNum == sockNum
&& (*streamsPtr)->fStreamChannelId == streamChannelId) {
- SocketDescriptor* socketDescriptor
- = lookupSocketDescriptor(envir(), sockNum);
- if (socketDescriptor != NULL) {
- socketDescriptor->deregisterRTPInterface(streamChannelId);
- // Note: This may delete "socketDescriptor",
- // if no more interfaces are using this socket
- }
// Remove the record pointed to by *streamsPtr :
tcpStreamRecord* next = (*streamsPtr)->fNext;
(*streamsPtr)->fNext = NULL;
--- 136,141 ----
_______________________________________________
live-devel mailing list
live-devel@lists.live555.com
http://lists.live555.com/mailman/listinfo/live-devel
