[e2e] Is this a bug with Windows TCP Stack ?

[Tommy Marcus McGuire]

I've seen comments about shutdown() like Sanjay's before, and either I
don't understand the comments, or the use of shutdown().

I've only used shutdown() to close half of the two-way connection,
either to indicate that I'm not writing anything more on it (Which will
result in an end-of-file condition when the FIN gets to the receiver.)
or to indicate that my end is not going to be reading anything (Which is
rare; I'm not sure what would happen if the other end of the connection
tried to write to it.  A RST maybe?).

If I don't care about the connection at all, I call close() and forget
about it.  If the other side wants to write to the connection, it will
get a RST, but that's not my problem.  If the other side is still
reading, it will get the FIN.  The TCP stack on the local machine should
handle the wait states just fine.

What I've seen (and interpret Sanjay's comments below to mean) is advice
to use shutdown() (for both halves of the connection) and then close(),
which doesn't make sense---the close() should report a local error
since the shutdown has already done everything the close would do.  Is
a close() on a previously-shutdown() connection supposed to generate a
RST?  If so, why?  Like Joe said, there's no error here.

On Wed, Dec 08, 2004 at 09:16:13PM -0800, Joe Touch wrote:
> sanjay kaniyar wrote:
> >RST is sent out because the application does not care about the connection
> >anymore.
> 
> "not care" is not an error.
> 
> RST is supposed to go out only for a transport protocol error or an
> application ABORT. Abort doesn't carry the 'I don't care' semantics;
> it's deliberate blowing away of state, and should be used with caution, IMO.
> 
> >For instance, say an application sent data, issued a Shutdown() to
> >close the connection gracefully - it waits for a duration of its choice but
> >the disconnect does not complete and it wants to abort the connection. The
> >Close() enables the application do exactly that.
> 
> Why does it need to abort the connection? If the disconnect doesn't
> complete, the CLOSE should resend the FIN. If the FIN arrives and a RST
> is sent in response, so be it, but that's what would happen - not the
> other way around.
> 
> Besides, disconnect only means "I have nothing more to send" - closes 
> are half-closes, not full, in TCP. If what you wanted was "close both 
> ends", you are better off picking (or designing) another protocol, 
> rather than abusing TCP.


-- 
Tommy McGuire