[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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



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


Magnus Westerlund wrote:

> 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
>
> Venkat N wrote:
>
> > 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/
> >
> >
> >
> >
> >
> >
>
> 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


_______________________________________________
mmusic mailing list
mmusic@ietf.org
https://www1.ietf.org/mailman/listinfo/mmusic