2 Jan
2007
2 Jan
'07
6:34 p.m.
John R. wrote:
What do you mean by "allowable RST?" RST can
be thought of as
hard-close, or "Sorry peer, I don't have any context about the
connection you sent a packet for," or "this port is not accepting
connections."
It is always allowed. It is not the ideal way to close a connection,
but as a peer receiving it you must always handle it, and you may send
it if you have a good reason.
Some consideration may be given to detecting spoofed RSTs attempting
to interfere with valid connections. But I suspect you are not
terribly interested in complicating your code with such corner case at
this point (there are a lot of things like this if you really want to
get into it).
There are lots of rules in RFC 793 for RST segment generation and handling.
You don't want to just whack any connection that gets an RST. The RST
has to have correct sequence and ack numbers in the header. Correct can
be extended to mean 'in the allowable window'. Otherwise, somebody can
have some real fun with your server by just spraying random RST segments
at you.
I code my RST handling code such that the RST has to be within the
current receive window, which is how I read 793. I think I have misread
or misinterpreted, and I should include RST packets that are in my
window of previously sent (but not yet acknowledged) packets.
Corner cases are an interesting design problem. I could make the code
quite a bit smaller if I just tweaked the spec a bit. Things like not
supporting two sides to do active opens at each other can save code, and
it is not a commonly used feature. I might go back and start sprinkling
my code with #defines to delete features like that if they are not needed.