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

[Valentin Stefan]

Hello!
 
I’m working with LiveMedia library for several months
now and I’ve come to have a few questions/observations
about it.

First of all, I have to thank you for your great job
with this, because it saved me from having to write my
own RTP/RTSP routines (which would have taken me a
loooong time...). I studied other libraries as well,
but none of them was so complete as yours.

Now, getting to bussines :) :

(Light observations/suggestions)

1. A lot of class methods are private. Well, this gave
me quite a few headaches, because I needed
new/different functionality from the library classes,
but I couldn’t do much in this direction. I’m speaking
mainly of RTSPServer, RTSPClientSession classes (but
Groupsock and a few others are in the same situation).
If I remember correctly, RTSP is intended to easily
support extensions and exactly this I needed; but not
only for adding extensions to the protocol can the
derivation of these classes be useful... 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), 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.
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.
As I mentioned before, these are not the only classes
subject to the above problem, but with these I’ve felt
it more thorougly.

2. Regarding the "event driven" vs. multithreading
issue
(http://lists.live555.com/pipermail/live-devel/2006-March/004101.html),
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.
These being said, I’ve had no problems (so far) in
integrating LiveMedia library in a multithreaded
environment (required by the other components involved
in the application...)

((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. If the whole application is
closed at the same time, no problem would appear; but
what if, for some reasons, the (server) application is
still functioning after killing the LiveMedia
environment? The client application would see the
movie freezing and maybe would try pressing the
Pause/Play button on its preferred movie player (to
attempt some kind of refresh); this would be a fatal
action for the poor server that would surely crash
with Access Violation/Segmentation Fault error. The
reason for this is that the RTSPClientSession object
is still lurking around with corrupted information in
its internal variables. The client request will be
intercepted by
RTSPClientSession::incomingRequestHandler1() and from
here we’ll arrive at RTSPClientSession::noteLiveness()
method, where any of that lines would access invalid
data (the server, the environment, task scheduler and
friends have long died). The problem seems not to be
fixed in the 2006.03.15 version of the library. Well,
to be 100% correct, the environment is not really
destroyed if you use its reclaim() method, but no one
stops me from directly deleting it (not that I have
done that). I don’t know why the existence of the
reclaim() method, instead of putting the code directly
inside the destructor. Anyway, that would not resolve
the problem, because the TaskScheduler is an external
pointer object and when it is deleted all other
considerations are useless (the environment has no
clue about that). I think it would be better that when
you request the environment to be destroyed, your wish
would be respected as soon as possible, because,
probably, you had your reasons when you asked that...
And, in the same time, the RTSPClientSession objects
should be destroyed too.

Well, these were my observations. I hope I didn’t
bother you too much. If I’ve mistaken in some of the
above problems (especially point 3), please let me
know.


Regards, 
Valentin


__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com