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

Alan Cox <alan@lxorguk.ukuu.org.uk> writes:
>> No, it doesn't "hang for all eternity", it sits in the same state until
>> (a) the client side closes its sending side of the connection (ie, sends
>> FIN), or (b) the FIN-WAIT-1 state times out.  But given a normally
>> responsive client and no loss of physical connectivity or crash of
>> either TCP stack, there is no connection reset and no failure to deliver
>> sent data.

> I cannot ack the data since it has not been read, so how can I ack the fin ?

ACK does not mean that you've delivered the data to the end user.
RFC 793, 2.6:
 An acknowledgment by TCP does not guarantee that the data has been delivered to the end user, but only that the
receivingTCP has taken the responsibility to do so.
 

Bit-bucketing the data because the end user app is no longer present to
accept it (due to having already closed its input socket) is implicitly
within the receiving TCP's authority here.  I think this is the core of
our disagreement, but I can see no justification for your position that
ACK implies the data has been delivered to the end user.  Every TCP
implementation I've ever heard of sends ACK as soon as it's collected
data into kernel buffers, *not* after the application has executed
recv() to extract the data from the kernel.  (Who's to say that
completion of recv() represents final delivery of the data anyway?
Sending ACK cannot be considered a report of end-to-end delivery;
that has to be an application-level concept.)

Also observe that the discussion of segment-arrival processing in
section 3.9 explicitly says that the behavior in FIN-WAIT-1 and later
states is not different from the behavior in ESTABLISHED state.  In
particular, if you do not like the segment:
       If an incoming segment is not acceptable, an acknowledgment       should be sent in reply (unless the RST bit is
set,if so drop       the segment and return):
 
         <SEQ=SND.NXT><ACK=RCV.NXT><CTL=ACK>
       After sending the acknowledgment, drop the unacceptable segment       and return.

There is no room here for the TCP to decide to send RST instead.
        regards, tom lane