Re: [tcpm] Is this a problem?

[MURALI BASHYAM <[e-mail]>]

This behaviour can and does get exhibited by standard web servers also, it's not only our application. The solution must 
work in scenarios where the application can cleanup its connection state, expecting TCP to deliver the data reliably to the peer after that.
It's not a broken application, this is a perfectly legal scenario. As far as the app is concerned, it's done with that connection, it can devote
that connection memory and resources  to another user or client, thus increasing goodput.

----- 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:40:10 AM
Subject: Re: [tcpm] Is this a problem?




MURALI BASHYAM wrote:
> 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.

It still sounds like you have a poorly written application to me;
 anyone
else?


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