Connection resets should be rare. If this is something you're
encountering consistently, I would suspect a buggy TCP stack.
I don't know if this makes sense, but TCP uses a finite state machine
to drive protocol operation. The basic packet structure (called a
"frame" at this level, or a TPDU if you want to sound a bit haughty)
includes a header that may have one or more flags set. The most
common ones are SYN (synchronize), ACK (acknowledgment -
acknowledgments are "piggy-backed" on normal data frames), and FIN
(final). Normally, you should never see RST. Anyway, TCP is designed
to be robust against certain types of errors: lost or duplicated
packets and packets delivered out of order. But it is still driven by
a state machine, and if the state machine gets into an "impossible"
state (i.e., if something happens that should never happen in its
current state), it sends a reset and gives up.
===
Gregory Woodhouse
[EMAIL PROTECTED]
"Perfection is achieved, not when there is nothing more to add, but
when there is nothing left to take away."
-- Antoine de Saint-Exupery
On Jul 25, 2005, at 8:04 PM, Gregory Woodhouse wrote:
At the protocol level, this means the reset flag was set in a TCP
frame sent by the server. This is the equivalent of throwing up
one's hands and saying "let's just give up on this connection and
start over". A connection reset may reflect a problem at the server
end, or it may indicate a protocol error on the part of the sender
from which the receiver is unable to recover.
-------------------------------------------------------
SF.Net email is sponsored by: Discover Easy Linux Migration Strategies
from IBM. Find simple to follow Roadmaps, straightforward articles,
informative Webcasts and more! Get everything you need to get up to
speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click
_______________________________________________
Hardhats-members mailing list
Hardhats-members@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/hardhats-members
