Re: Fwd: Re: Fwd: Problem with recv syscall on socket when other side closed connection

kuznet@ms2.inr.ac.ru writes:
> I apologize, but RFC793 is sort of incomplete. Please, look at
> errata in RFC1122 and to bug alerts described in documents published
> by tcp-impl (draft-tcpimpl-*).

The errata in RFC 1122 do not recommend any changes in connection
closure behavior.  You appear to be hanging your hat on this paragraph
from 1122 4.2.2.13:
           A host MAY implement a "half-duplex" TCP close sequence, so           that an application that has called
CLOSEcannot continue to           read data from the connection.  If such a host issues a           CLOSE call while
receiveddata is still pending in TCP, or           if new data is received after CLOSE is called, its TCP
SHOULDsend a RST to show that data was lost.
 

However I read this as a requirement pertaining only to half-duplex
close sequences.  There is nothing half-duplex about closing a socket
completely.  In any case, it can hardly be a good idea to abort the
flow of data in the outbound direction in order to report that data
is being dropped in the inbound direction.  If an application has done
a half-close to close its inbound side only, but wants to keep sending
outbound data, it presumably has a good reason for doing so.  Behaving
as you suggest would render this mode of operation useless.

As for the drafts, I assume you are referring to sections 2.16 and 2.17
of RFC 2525 --- I couldn't find anything about connection resets in
the other files ftp://ftp.isi.edu/internet-drafts/draft-ietf-tcpimpl-*.
May I remind you that 2525 is an informational RFC, not a
standards-track RFC, and accordingly it has not been reviewed to the
extent that a proposed standards change would be?

I shall be writing to the authors of 2525 to object to sections 2.16
and 2.17 on the grounds that an RST causes data loss in the other
direction.  We'll see what they have to say.

> From the viewpoint of application, the behaviour is also correct.
> Data arrived, when nobody plans to read it, unambiguously means
> either connection abort or hard bug in application protocol.

Sure, it's a connection abort.  My point is that RST is an unacceptably
blunt instrument for reporting it, because it causes loss of data going
in the other direction.
        regards, tom lane