Re: [tcpm] Is this a problem?

[Ethan Blanton <[e-mail]>]

(Apologies for the duplicate, Joe, I didn't reply-to-list.)

Joe Touch spake unto us the following wisdom:
> > 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 is my understanding (correct me if I am wrong) that close() returns
immediately, regardless of queued data in the send buffer.  In
addition, I am not aware of any way to force a reset on a TCP socket
without pending data in the read buffer.

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

Agreed, to some extent.

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