On 7 maj 2014, at 21:28, Ross Finlayson <finlay...@live555.com> wrote:
>> Based on what I see it seems as if Live555 does not properly clean up the
>> first session when the
>> connection breaks. Instead it seems to close the wrong connection when the
>> time out occurs.
>
> No, based on your description I'm not seeing any incorrect server behavior.
> The server is timing out the first connection (and deleting the
> "RTSPClientConnection" object) 65 seconds after you kill the first client
> (without having it send a "TEARDOWN"). The second client then causes a new
> "RTSPClientConnection" object to get created. (It happens to have the same
> address - 0x10c008000 - as the old "RTSPClientConnection" object, but it's a
> new object.)
>
> The reason why the server stops streaming to the second client after the
> first client has timed out is most likely due to a problem with your own
> additions to the server - i.e., either your own
> "OnDemandServerMediaMediaSubsession" subclass, and/or your own "FramedSource"
> subclass.
>
> First, when your "OnDemandServerMediaMediaSubsession" subclass's constructor
> calls the "OnDemandServerMediaMediaSubsession" constructor, then make sure
> that the "reuseFirstSource" parameter is "True". This ensures that - if two
> or more clients request the stream concurrently - then your "FramedSource"
> subclass (i.e., your data source class) will be created only once.
>
> Second, you must allow for the possibility of your "FramedSource" subclass
> object being closed, then recreated - perhaps multiple times. If you set
> "reuseFirstSource" to "True" (as noted above), then you will never see your
> "FramedSource" subclass constructor being called more than once before the
> destructor is called - but you may see "constructor", "destructor",
> "constructor", "destructor", etc. Your "FramedSource" subclass's
> constructors and destructors must allow for this to happen.
>
> Finally, if you want to test the behavior of your server, then you should
> first do so using our "openRTSP" client (note the "-t" option to request
> RTP/RTCP-over-TCP streaming), not with some random other client (that might
> use a different - perhaps broken - RTSP client implementation). Similarly,
> if you want to test the behavior of your own client, then you should first do
> so using "testOnDemandRTSPServer" or the "LIVE555 Media Server" as the
> server. This is common sense. If you want to test a client-server
> combination, then start with one combination that you know works OK
> ("testOnDemandRTSPServer" with "openRTSP"), then change only one end at a
> time as you continue your testing.
I can not reproduce the same problem when using openRTSP or
testOnDemandRTSPServer. My own client also behaves ok.
I'm at a total loss as to what in my server code could cause only TCP to
misbehave. I've spent enough time trying to debug that and
must move on for now. I hope to find the problem later when I get more familiar
with Live555, it's not an easy library to use.
I'm sorry for the time I've wasted for all readers.
One thing I did notice however that causes testOnDemandRTSPServer to freeze is
to do like this:
1. start testOnDemandRTSPServer and stream something (in my case a H264 file)
2. start openRTSP #1 against the server
3. start openRTSP #2 against the server
4. suspend #1 through C-z to simulate a bad network connection
5. #2 will now not get any more data and the server is totally frozen until #1
is resumed
--
Jan Ekholm
jan.ekh...@d-pointer.com
_______________________________________________
live-devel mailing list
live-devel@lists.live555.com
http://lists.live555.com/mailman/listinfo/live-devel
