[Live-devel] Design flexibility issues and A possible bug in RTSPServer/RTSPClientSession

[Ross Finlayson]

>My point is
>that I see no reason why you don’t make the majority
>of the methods protected (and virtual) (instead of
>making them "brutaly" private)

Yes, you're probably right - I have generally 
erred on the side of conservatism here.

If you have some specific examples of "private" 
methods that you would like to see changed to 
"protected", then let me know, and I'll look into 
changing them in future releases of the code.

>, because you have to
>have some trust in the so called "client programmers"
>­ the ones that use your library ­ that they know what
>they are doing.

Unfortunately, as much of the traffic on this 
mailing list shows, that is not always the case :-) :-)

>Somewhat related to this, would be the direct creation
>of a new RTSPClientSession instance in the
>RTSPServer::incomingConnectionHandler1() method. I’d
>humbly suggest that calling some factory method (that,
>of course, would return an instance of a
>RTSPClientSession or a derived class) would be more
>appropriate.

Yes, that's a good idea.  I'll probably do this in a future release.

>2. Regarding the "event driven" vs. multithreading
>issue
>(http://lists.live555.com/pipermail/live-devel/2006-March/004101.html)

I assume you've also read 
<http://www.live555.com/liveMedia/faq.html#threads> 
(and <http://www.softpanorama.org/People/Ousterhout/Threads/tsld001.htm>)

>I think a point in favor of multithreading programming
>would be the nature of the problem that this library
>addresses: multimedia streaming and the trend that the
>IT hardware industry appears to be on: the
>increasingly use of dual and multicore processors.

There are pros and cons to the single-threaded, 
event-driven architecture that the "LIVE555 
Streaming Media" uses, but (as someone who first 
programmed with threads more than 20 years ago) I 
believe that the pros significantly outweigh the 
cons.  Multithreaded code is significantly harder 
to develop and (especially) debug, and very few 
people have the expertise to do this well.

As I note in the FAQ, there are ways to use this 
code in a multithreaded application, if you really want to do this.

>((More) serious problem)
>
>3. When some RTSP client connects to LiveMedia’s
>RTSPServer, a new RTSPClientSession instance is
>created. This new instance appears to be on its own,
>the RTSPServer caring no more about its existence. If,
>at some point along the way, the RTSPServer object
>(along with the whole LiveMedia environment) is
>killed, the RTSPClientSessions remain alive in some
>kind of "zombie" fashion.

That was intentional.  It simplifies the code 
(because the "RTSPServer" doesn't have to keep 
track of "RTSPClientSession"s).  However, on 
reflection it would probably have been better for 
the "RTSPServer" to keep track of the 
"RTSPClientSession"s (e.g., in a hash table), and 
to delete them all in the "RTSPServer" 
destructor.  I may make this change in a future 
release (along with the "RTSPClientSession" 
'factory' change that you suggested).


	Ross Finlayson
	Live Networks, Inc. (LIVE555.COM)
	<http://www.live555.com/>