Re: [tcpm] Is this a problem?

[Ethan Blanton <[e-mail]>]

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

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.

Ethan

-- 
The laws that forbid the carrying of arms are laws [that have no remedy
for evils].  They disarm only those who are neither inclined nor
determined to commit crimes.
		-- Cesare Beccaria, "On Crimes and Punishments", 1764

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