TCP reset messages
rick.jones2 at hp.com
Tue May 30 19:08:34 UTC 2006
Larry Adamiec <ladamiec at yahoo.com> wrote:
> On occasion, I receive the following error:
> May 25 06:18:02.371 dispatch: error: dispatch 0b6540:
> shutting down due to TCP receive error: connection reset
> From what I have read, this error is usually caused by the remote
> side not disconnecting properly.
> So, is this error preventable? If so, how? Or do you simply ignore
> these errors?
Well.... That all depends I suspect - is it just "connection reset" or
is it "connection reset by peer?" (Perhaps they are the same, I'm
just being a triffle paranoid).
Connection reset by peer means we received a RST segment from the
remote. It could be:
*) The remote was trying to send us data, but either his data or our
ACK's were not getting through, and when he gave-up the RST
*) The remote called close(), or shutdown(SHUT_RDWR), but not just
shutdown(SHUT_WR) on his socket before some data we were sending
him arrived. The application doing those first two tells TCP that
no more data is expected, and if some arrives TCP says "whoa, that
wasn't supposed to happen" and triggers the RST as a way of saying
"Hey, you guys have your connection close handshake fubar."
The fundamentally asynchronous nature of networking means you
wouldn't see the RST on the send() of the data that triggered the
RST but on something called later - a read/recv, perhaps another
*) There is some end-to-end breaking, busted POS firewall between the
two of us and it got uppity.
If "connection reset" is not the same as "... by peer" my guess is
that most likely an attempt to transmit data to the remote hit a
retransmission timeout limit - although I would have expected an
ETIMEDOUT in that case.
firebug n, the idiot who tosses a lit cigarette out his car window
these opinions are mine, all mine; HP might not want them anyway... :)
feel free to post, OR email to rick.jones2 in hp.com but NOT BOTH...
More information about the bind-users