[e2e] RST effect on socket buffers?

rick jones perfgeek at mac.com
Wed Jan 5 08:28:22 PST 2005


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



More information about the end2end-interest mailing list