[e2e] RST effect on socket buffers?

[rick jones]

On Jan 4, 2005, at 11:35 PM, Tristan Horn wrote:

> Hi all,
>
> I find myself wrestling with a vendor to get their HTTP proxy's 
> half-closed connection handling fixed.
>
> One of the issues is that their hardware sends a spurious RST to the 
> client after a 60 second timeout.  The effect is that any data 
> remaining in the client TCP's receive buffer appears to vanish; the 
> application is not able to read it.

Half-closed at which end?  If the proxy has the FIN_WAIT_2, then their 
stack may have an arbitrary fin_wait timer as an overly defensive 
measure to prevent having a FIN_WAIT_2 connection remain indefinitely 
when the remote evaporates before sending a FIN.  Such timers are often 
requested of vendors by their customers.  Particularly when those 
customers have clients which are overly fond of abortive closes at 
their end - the RST's get lost and are not retransmitted.

Or, the proxy software may have issued a shutdown(), and waited the 60 
seconds itself for the client to do the same, and then set SO_LINGER 
and called close() - a measure similarly defensive.

> My casual reading of RFC 793 suggests that this behavior is expected:
> * a connection in e.g. ESTABLISHED state will transition to CLOSED 
> upon  the receipt of a valid RST,
> * "CLOSED" == "non-existent"
>

which behaviour - sending the RST in the first place, or the effect of 
the RST on the connection?  The former is not "expected" the latter is.

> The vendor doesn't agree.  I also seem to only be able to replicate 
> the problem on Windows, not e.g. Linux...

Sounds like the arbitrary timer in the stack then. Although you may 
want to syscall trace the proxy if you can.

> Can anyone shed light on what the expected behavior here is (if any)?

Personally, I believe that once a TCP has been in  FIN_WAIT_2 for some 
length of time it should start sending keepalive probes to make sure 
the remote is still there and if it hasn't received a response to the 
keepalive probes within R2 (?) - the configured retransmission limit, 
_then_ it should abort the connection with a RST just like a normal 
data retransmit. As presently defined (IIRC) FIN_WAIT_2 is a state 
where the local TCP will do nothing until it recieves a segment from 
the remote, and there are no guarantess the remote will actually be 
there.

rick jones
there is no rest for the wicked, yet the virtuous have no pillows