[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [MMUSIC] RTSP: Connectionless vs. connection-based
Hi Vivek and Thomas,
See my comments to both your mails inline.
Vivek Mudgil wrote:
> It has been an interesting reading this discussion on connectionless
> vs connection-based. Logically
> it would make more sense if clients send the "I am alive" signal to
> the server. This philosophically is in line with the concept of load
> distribution.
Yes, I agree with you that it is a responsibility of the client to keep
the connection alive. This would be in line with that it also is the
clients responsibility to keep the RTSP session alive. However the
server may of course try to ping the client before closing the
connection. We can't mandate such a mechanism but it be a may or
recommended. Also I do believe that an options tag for this could be
beneficial. That way the client will know how the server will behave.
>
> Secondly I was just wondering why can't the "persistent connection" be
> made a default option for
> RTSP connection with a time out on server side. This passes the onus
> of keeping the connection alive to the clients. Clients may have a
> configurable parameter which will allow the user to decide whether it
> wishes to work in persistent mode by periodically sending the
> "connection alive" signal or wishes to run in connectionless mode by
> closing the connection after each transaction. This is turn will be
> based on delay performance observed by the user in re-establishment of
> connection.
>
I don't want to make it default because that may result in loss of
backwards compatibility towards non-persistent connections. To my
understanding persistent connections is a special case of
non-persistent. My goal is to write the specification so that makes no
difference for the server to support both modes. The client has the
choice to use what suits it. I do believe we are aiming for the same
goal, let the client choose.
> Thomas Zeng wrote:
>
>>Hi Magnus:
>>
>>In the message below you suggest that "the server shall not
>>close the a connection unless at least the RTSP session time-out has
>>passed without traffic."
>>
>>Later on you seem to imply that the onus is on the client to make sure
>>that it sends a message (could be some keep alive message such as
>>OPTIONS) at least every 60 seconds (or according to RTSP timeout interval).
>>(Or did you mean
>>the server is to ensure one message every 60 seconds? It was not clear to
>>me... hence this email...)
>>
It is the client that needs to send regular keep alive messages.
>>
>>How about putting the onus on the server to ping the client when RTSP
>>session time-out
>>expires, and only kick out the client if no ping-response is receive after a
>>"RTSP response
>>timeout" (again a negotiable value, perhaps a few seconds)?
>>
I can see the usefulness of this, but the default behavior must remain
that it is the responsibility of the client. An options tag could be
used by the server in a supported header to tell the client that it has
this capability. Such a mechanism can be used for both the RTSP timeout
and the connection timeout. Should both be included in the same tag or
could they be separately implemented?
Thomas, could you draft a paragraph defining this for the connection to
be included in the proposed section 9.3. I would like it to also define
the options tag to use.
>>
>>I say because I may have thin clients that I'd like to keep as simple as
>>possible. Servers on the other hand
>>have more leeway.
>>
Implementing a keep alive mechanism is still required for the client.
Otherwise it will lose the RTSP session, it can of course rely on RTCP.
But if the code to implement a timer that sends regular connection and
session keep alive is to much, I would recommend that this client use
non-persistent connections.
Best regards
Magnus Westerlund
Multimedia Technologies, Ericsson Research ERA/TVA/A
----------------------------------------------------------------------
Ericsson AB | Phone +46 8 4048287
Torshamsgatan 23 | Fax +46 8 7575550
S-164 80 Stockholm, Sweden | mailto: magnus.westerlund@era.ericsson.se
_______________________________________________
mmusic mailing list
mmusic@ietf.org
https://www1.ietf.org/mailman/listinfo/mmusic