Re: [tcpm] Is this a problem?

[Joe Touch <[e-mail]>]

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
> work in scenarios where the application can cleanup its connection state, expecting TCP to deliver the data reliably to the peer after that.

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.

> 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.

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

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