There are two things we could consider here :
1.
I presume that most application protocols like ftp implement
timeouts in such a way that a crossing of a particular time-period
would imply closing the connection (i.e if nothing comes from
the client
then it is as good as connection closed ).
2. If the connnection has to be maintained for a long time
period then
there arises a possibility of using SO_KEEPALIVE .
On linux systems this is present in the file proc/sys/net/ipv4/tcp_keepalive_time
and defaults to 7200 secs .
This seems too big a value and would affect all TCP connections
with the
option set.
Another possibility could be a mechanism running btn client
and server for maintaining the connections.The drawback
with this approach is that it may not be applicable to
all clients as the protocol or mechanism is only between
a particular client and server .
It looks to me that keeping the connection open for sending
a subsequent "SETUP" request is definitely an advantage
but we also need to consider the polling done by the server
on all the connected filedescriptors. If there are 100 connections
to a server and 90 of them are idle for a long time then this
would amount to clogging the system resources.
So deciding on the timeout is still a question and my view is
that the connection
need not remain open if there is no transmission of data .
-- Regards, -Venkat Visit http://cdn.hcltech.com/
Magnus Westerlund wrote:
Hi Jonathan,Yes, I made a mistake and did not thought of the implications having a
session time-out effect the connections. I agree with you that the
transport connections and sessions should be decoupled. A RTSP message
to a session should only be forward to the session based on the session
id header.This decoupling would result in that two different time-outs must exist.
One for the RTSP session which functions as discussed earlier. The other
takes care of the transport connections.So how do we solve the time-out of the transport connections? The goal
as I see it, is that the server should not close any connections unless
the client has stopped using them and forgotten to close them. If this
can be used it will avoid the potential backwards compatibility issues.
The implications such a scheme will have on security is a valid
question. What are the possibilities for an attacker to use up all
available connections to a server by opening connections and keeping
them alive with regular messages? Will this port exhaustion attack be
less a problem with larger possibilities for a server to close connections?My TCP knowledge is not that good, what type of keep-alive exist within
TCP. Can this be used to reliably determine when the client has
forgotten to close a connection to the server and is not any longer
responding? Also what time-out does this keep-alive have if it exist?Hope that we can solve this problem
Magnus
Jonathan Sergent wrote:
>On Mon, Jun 17, 2002 at 09:00:10AM +0200, Magnus Westerlund wrote:
>
>>"The server should never close a connection unless the session times
>>out, even not after teardown of the session."
>>
>
>This means that the server has to know which sessions are bound to
>which connections, which is what I was trying to avoid, since it is
>potentially troublesome to implement. What if you reference a single
>session on multiple connections? Which connection does the session
>keep open? All of them? The most recently used one? It is not
>obvious what the client will expect.
>
>If the answer is "all of them", this seems like an easy opportunity for
>clients to cause the server to keep lots of connections open, since it
>only needs to send traffic with the session ID on one connection to
>keep all of them open.
>
>--
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