Subject: Re: [tcpm] Is this a problem?

From: MURALI BASHYAM <[email-masked]>
Date: Tue, 6 Nov 2007 10:50:50 -0800 (PST)

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 <[email-masked]>
To: MURALI BASHYAM <[email-masked]>
Cc: Lloyd Wood <[email-masked]>; [email-masked]
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
[email-masked]
https://www1.ietf.org/mailman/listinfo/tcpm

---

From: Joe Touch <[email-masked]>
Date: Tue, 06 Nov 2007 11:03:26 -0800

MURALI BASHYAM wrote:
> This behaviour can and does get exhibited by standard web servers also, it's not only our application.

So multiple apps are broken - this has happened before.

> The solution must

There is a disconnect in believing that TCP ever needs to clean up its
connection state. TCP tends to leave state around and clean it up when a
new connection overtakes it; it does not tend to clean things up.

> that connection memory and resources  to another user or client, thus increasing goodput.

As you note the resources don't get released until the data is
transferred or the connection is aborted, so it's a misconception that
the application should close a connection to release memory and resources.

Finally, it sounds like you didn't want a nonblocking CLOSE; you want to
use a blocking CLOSE with an application timeout timer.

Joe