Re: [tcpm] Is this a problem?

[Joe Touch <[e-mail]>]

Ethan Blanton wrote:
> (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.  ...

See, e.g.:
http://www.developerweb.net/forum/archive/index.php/t-2982.html

> In
> addition, I am not aware of any way to force a reset on a TCP socket
> without pending data in the read buffer.

ABORT is defined to do this, and does not require pending data in the
buffer AFAICT.

Joe

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