TCP reset messages

Rick Jones rick.jones2 at
Tue May 30 19:08:34 UTC 2006

Larry Adamiec <ladamiec at> 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
   actually got-through.

*) 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
   send() call.

*) 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.

rick jones
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 but NOT BOTH...

More information about the bind-users mailing list