Subject: Re: [MMUSIC] RTSP: Connectionless vs. connection-based

From: [email-masked]
Date: Mon, 17 Jun 2002 14:52:42 +0200

but a server *has* to garbage collect inactive sessions, otherwise it would be a sitting duck for DOSA !

Philippe Gentric
Software Architect
Philips MP4Net
[email-masked]
http://www.mpeg-4.philips.com

                      Magnus Westerlund                                                                                                        
                      <[email-masked]             To:  Jonathan Sergent <[email-masked]>                                             
                      ricsson.se>                          cc:  "[email-masked]" <[email-masked]>                                            
                      Sent by:                              (bcc: Philippe Gentric/MP4-SUR/CE/PHILIPS)                                         
                      [email-masked]                Subject:   Re: [MMUSIC] RTSP: Connectionless vs. connection-based                   
                                                                                                                                               
                                                           Classification:                                                                     
                      17/06/2002 09:00                                                                                                         

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:

>
> On Thursday, June 13, 2002, at 04:42 AM, Magnus Westerlund wrote:
>
>> -  Any RTSP message with the sessions ID. A list in order of
>> preference of use should be established: Ping, Options with session
>> header.
>> -  RTCP messages from the client for the RTP sessions attached to the
>> session's media streams.
>> - The TCP connection if it has keep alive messages verifying that
>> connectivity exist. (I am a little doubting about this. This may not
>> show an application failure correctly)
>>
>> My point is that persistent TCP is actually a special case of
>> non-persistent, and if a server implements non-persistent correctly
>> it will work fine when the client do not close the TCP connection.
>
>
> This doesn't deal with the server closing the connection.  Should the
> server be able to close the connection after PLAY and assume the
> client will reconnect if it wants to send a PAUSE?  If the client does
> not expect this, it may stop playing the stream when this happens.
>
> --jss.
>
>
>
> _______________________________________________
> mmusic mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/mmusic
>

--

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: [email-masked]

_______________________________________________
mmusic mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/mmusic

_______________________________________________
mmusic mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/mmusic

---

From: Magnus Westerlund <[email-masked]>
Date: Mon, 17 Jun 2002 16:10:58 +0200

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

Magnus Westerlund

---

From: Venkat N <[email-masked]>
Date: Tue, 18 Jun 2002 13:44:04 +0530

Hi Magnus,

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/

---

From: Magnus Westerlund <[email-masked]>
Date: Tue, 18 Jun 2002 09:44:33 +0200

Hi Venkat,

I agree with your points. As a clarification and in reference to to my 
latest message to jonathan, there is need for time-out on both the RTSP 
session and the transport connection. If any of the time-out happens, 
the resources related to time-out can be released. What we haven't 
resolved so far is what the value of the transport time-out is and how 
it should work.

Regards

Magnus 

Magnus Westerlund

---

From: Narsimha Reddy CH <[email-masked]>
Date: Tue, 18 Jun 2002 14:47:23 +0530

Hi Magnus,

  The following  are the  points that I have in mind regarding TCP
   transmission timeout ,

  If the server is simply waiting for data from the client, there is
  no way  to tell if the peer has silently gone away, or just isn't
  ready to send any more data yet.  Due to this the server
  may run out of resources after some time.

  The solution could be to use the KEEPALIVEs.  The transport
  layer periodically probes the connection to ensure that the
  connection is alive.  As far as I know the default timeout is 2 hours
  on most unix flavours.  It can be set to a different value in most
  UNIX systems through a kernel parameter and will then affect
  all the TCP connections with the option set.

  But this doesn't make any sense for shortlived connections ( in
  case of  other protocols ) to keep the connection open  even if
  there is no data flowing.

   Regards,
- Narsimha Reddy CH