On Fri, 26 Mar 2004, Biot Olivier wrote:
> I don't want to add to the polemic, but I can add a note of what I've
> personally seen in practice :)
Me too :-)
> The RST trick will do a "fine" job in most of the "well-behaved" networks...
> where the TCP (client) protocol stack implements the state transition from
> all states (different from SYN-RECEIVED) when receiving a RST.
>
> >From the moment that you get network (or CPU) congestion, or multiple
> routes, or you're talking about wireless links, you *cannot* guarantee the
> in-sequence delivery of messages. As a result, if the server sends an ACK
> segment and after some time a RST segment, the possibility that the RST
> arrives to the client *before* the ACK has to be considered.
I think that the point of the trick is that it is:
1. Server initiated
2. Probably only used for HTTP1.0 because there should not be another
request coming down the connection.
Thus, when the server sees the ACK for all the data sent for the response
to the previons HTTP request, it can drop the connection by issuing an
RST and then scoot around to handle another request, rather than wait for
the FIN ACK sequence to be done.
Regards
-----
Richard Sharpe, rsharpe[at]richardsharpe.com, rsharpe[at]samba.org,
sharpe[at]ethereal.com, http://www.richardsharpe.com