Re: [tcpm] Is this a problem?

[MURALI BASHYAM <[e-mail]>]

We want to limit the timer to the sender's persist state only, any other timeout overloads the semantics of the application,
and may also cause unnecessary timeouts for the application. In fact there are instances where the application may not
even have the connection state around to implement the timout correctly, like the tail of a long HTTP response. After sending the tail of the 
response, the application can close the connection and release its connection memory, during this window only TCP has the 
connection state. We've done a lot of testing and design  for handling all these cases, and to implement this correctly, 
we need TCP's involvement.

Murali

----- Original Message ----
From: Joe Touch <[e-mail]>
To: MURALI BASHYAM <[e-mail]>
Cc: Lloyd Wood <[e-mail]>; [e-mail]
Sent: Tuesday, November 6, 2007 10:24:49 AM
Subject: Re: [tcpm] Is this a problem?




MURALI BASHYAM wrote:
> In the spirit of keeping changes to TCP protocol minimal, how about
> having the application specify a time limit via the socket API when
 TCP gets into this
>  state and TCP cuts its indefinite wait down to this timeout? 

Why not set the timer in the application and ABORT or CLOSE the
connection when the timer goes off?

Joe





__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com 


_______________________________________________
tcpm mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/tcpm