[Live-devel] Reclaiming live clientsessions

Renato MAURO (Libero) renatomauro at libero.it
Mon Jan 19 04:07:30 PST 2009


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
> 




More information about the live-devel mailing list