Re: [tcpm] Is this a problem?

[Joe Touch <[e-mail]>]

Ethan Blanton wrote:
> Joe Touch spake unto us the following wisdom:
>> 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?
> 
> This comment of Murali's, specifically, is a case that the application
> *cannot* (portably or cleanly) handle, at least under the Berkeley
> sockets API.  He is correct that once an application writes the end of
> its data and calls close() or shutdown(), the TCP socket may persist
> indefinitely in the kernel, and the application would never know (if
> there are no application-level acknowledgments, as there are not in
> simple HTTP responses).

Why would a blocking CLOSE not solve that?

> It does not seem unreasonable to add a zero-window timeout tunable to
> any given TCP implementation; I don't necessarily think it is a TCP
> standardization issue, however, as there is no wire impact.

Protocols are more than just what is on the wire. They include state at
the endpoints, and APIs.

Joe

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