Few points which I have in mind:
The server should have the right to close the
connection in case of timeout and this right
need not always be with the client .
Assuming the client does not close the connection
and is not actually sending any request , then
in this case the server would be polling on this
filedescriptor also among the set of connected filedescriptors
which could be avoided .
When the client sends a TearDown , we understand that
the session is no longer valid and all resources have been
released .
The above implies that the connection is still valid and
a subsequent request by the client could take place in
the same connection instead of going for a "SETUP" in
a different connection .But here we also need to
consider how long can we have the connection alive .
-- Regards, -Venkat Visit http://cdn.hcltech.com/
Magnus Westerlund wrote:
Hi Philippe,I agree with you that a session must remove inactive sessions. However
as long as the client shows life signs at least once every timeout
interval (normally 60 seconds) the session is alive. And as long as the
client shows signs of life the server has no reason for closing the
connection.I will further clarify what I guess you misunderstood about teardown.
The server should not close a TCP connection as a response to the RTSP
teardown request for that session. The client might want to set up a new
session without spending unnecessary RTT on TCP connections. If the
client is through communicating with the server it should send a TCP close.Was there something else I was unclear about?
Regards
Magnus
philippe.gentric@philips.com wrote:
>
>but a server *has* to garbage collect inactive sessions, otherwise it would be a sitting duck for DOSA !
>
>
>
>Hi Jonathan,
>
>I had the following sentence in my previous letter which shows my view
>on the issue.
>
>"The server should never close a connection unless the session times
>out, even not after teardown of the session."
>
>So my answer to your question is NO, the server shall not close the
>connection. The connection was initiated by the client, so it is the
>clients to control and decide about. The only two reasons for the server
>to close a connection is a serious server internal error that can't be
>recovered from and when the server is taken off line and redirect has
>been issued in sufficient time before this event.
>
>Regards
>
>Magnus
>
>Jonathan Sergent wrote:
>
Magnus Westerlund
Multimedia Technologies, Ericsson Research ERA/TVA/A
----------------------------------------------------------------------
Ericsson Radio Systems 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