[Live-devel] OPTIONS vs GET_PARAMETER for keep alive with proxy server

[Craig Matsuura]

Thanks for the insight Jeff. After further digging I found the issue we were having.  I have moved back to OPTIONS as a keepalive.  I posted a patch to the mailing list but have not seen it approved.

Thanks,
Craig

On 03/04/2014 05:47 PM, Jeff Shanab wrote:
In my Archiver, Restreamer, and Player I have a watchdog that is kicked when frames come in. If I fail to get frames the watchdog expires; or if ever there is a socket error. It is a do-over. I start again with the DESCRIBE. I did my own server and there was never more than 1 stream from the camera, I reference counted my frames and when that reference count hit zero it returned the frame object to the pool.  Not sure if that answers your question.
Part of this is basic sockets. I was using TCP. It KNOWs when a connection is broken. I couldn't wait for it so I added the watchdog.


On Tue, Mar 4, 2014 at 6:59 PM, Craig Matsuura <cmatsuura at vivint.com<mailto:cmatsuura at vivint.com>> wrote:
It appears the GET_PARAMETER will accept the Session header as a OPTIONS does not care.  So if for some reason the camera server closes the session what is the indicator to the client?  If the GET_PARAMETER is sent with a Session I assume the camera server should respond with a 454 and not reply to the message with a 200?

In my logs it appears the Session header is sent in the OPTIONS command but assume a OPTIONS is not session dependent it will ignore any session header.

So I guess my point is how the session header would be honored in a OPTIONS vs GET_PARAMETER.  Seems the GET_PARAMETER is a better solution.

Thanks,
Craig


On 03/04/2014 04:32 PM, Ross Finlayson wrote:
I'm not sure I understand your question.

If the 'liveness' command from the proxy server (*either* "OPTIONS" or "GET_PARAMETER") fails - either because the TCP connection fails, or because the back-end server responded with a response code other than 200 - then the proxy server will assume that the session has failed,  It will then reset its state with the back-end server.  It will then attempt to send another "DESCRIBE" command (and then "SETUP", "PLAY", etc. for any subsequent front-end client connection(s).

Note that this is true *regardless* of whether the 'liveness' command is "OPTIONS" (by default), or "GET_PARAMETER" (if you've "#define"d SEND_GET_PARAMETER_IF_SUPPORTED).  So I don't understand the "OPTIONS vs GET_PARAMETER" in your "Subject:" line.


Ross Finlayson
Live Networks, Inc.
http://www.live555.com/



_______________________________________________
live-devel mailing list
live-devel at lists.live555.com<mailto:live-devel at lists.live555.com>
http://lists.live555.com/mailman/listinfo/live-devel



-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.live555.com/pipermail/live-devel/attachments/20140307/b2c62357/attachment.html>