[Live-devel] Reclaiming live clientsessions

[Matt Schuckmann]

I to have similar requirements in that a user may need to reconfigure 
the server ( different port, different sessions), etc without shutting 
down the main process.



Renato MAURO (Libero) wrote:
>
> Hi Ross.
>
>> Right now I'm not sure there's a clean way to delete RTSP sessions 
>> unless they are actually closed (using RTSP "TEARDOWN") beforehand, 
>> because otherwise any future incoming RTSP requests or RTCP packets 
>> might still try to be handled by the code, using deleted structures.
>>
>> However, as I said before:
>> You can also call "RTSPServer::removeServerMediaSession()".  This 
>> won't stop any existing stream (it will run until completion), but it 
>> will prevent any other clients from requesting the same data.
>>
>> But is this really a problem?  How often do you ever delete a RTSP 
>> server without destroying the application (process) that contains it. 
>> If you destroy the process, all the sockets (and thus client 
>> sessions) will get closed automatically.
>>
>> In summary: IMHO, there really isn't a problem/issue here that's 
>> important enough to address right now.
>> -- 
>
> I'm working with a security application (videosurveillance, burglar, 
> fire, access control), which has a 24/7 application.
> For instance there is an installation with a process started on June 
> 2007 and never closed.
>
> The process is never closed, even if an Administrator needs to change 
> the RTSPServer port (for firewall testing/maintenance) or a network 
> attack happens; in both cases, the process creates new Environment, 
> Groupsock, RTSPServer (with the new IP port), thread (doEventLoop) and 
> MediaSessions; then it closes old thread (by watch variable), 
> RTSPServer, Groupsock, Environment, in this order so no incoming RTSP 
> command creates any problem with realesed resources (I hope :-) ). 
> Each client will fall on "Data not available", so it closes the 
> current stream and connects to the new RTSPServer, getting the new 
> port from another encrypted socket, external to live555. In general, 
> if the process shutdowns, it is considered as a tamper attack.
>
> Since June 2007, one firewall test and twelve network attacks 
> occurred. The system manages 64 sessions, with normally 36 client 
> connected (other session are requested only in case of an alarm). Now, 
> with a memory profiler, the process has 462 undisposed 
> RTSPClientSessions. I need to follow the rule "each NEW wants its 
> DELETE, and wisely executed".
>
>
>> First, *do not* send the same message to the mailing list more than 
>> once!
>
> I'm sorry. Watching the mail tree, I wrongly guessed that my question 
> was out of thread and so ignored after your answer to sri kanth.
>
>> (Because you did this (and because you're using an unprofessional 
>> email address),
>
> I'm a free lance (project cooperator), I don't have any fixed company 
> e-mail address, nor I own a one-man company.
>
>> all future messages from you to the list will be moderated.)
>
> What could/have I do to avoid this?
>
>
> Thanks for your help and I apologize for any problem or time waste I 
> caused.
>
> Renato MAURO
>
>
>
>
>
>
>>
>> Ross Finlayson
>> Live Networks, Inc.
>> http://www.live555.com/
>> _______________________________________________
>> live-devel mailing list
>> live-devel at lists.live555.com
>> http://lists.live555.com/mailman/listinfo/live-devel
>>
>
>
> _______________________________________________
> live-devel mailing list
> live-devel at lists.live555.com
> http://lists.live555.com/mailman/listinfo/live-devel
>