I have my server and client apps. Client connect to server and send some byte arrays to server. Some time client and server lose connection and I catch SocketException: Connection reset. This exception occurs from time to time.
Can anybody explain what does it mean and how I can fix it or at least avoid it.
There are two kinds of connection resets: remote and local. Often seen as "connection reset by peer" and "software caused connection abort" ("software" here meaning "the local TCP/IP stack software decided something was wrong and broke the connection, as opposed to an abort caused by receiving an RST packet").
When a TCP/IP stack notices something broken about the connection, it sends an RST to the other end to tell it "hey, our connection is screwed, let's close it."
I suspect listing all situations where RST might happen could be a difficult task... But some reasons might be:
- The peer received a packet that is not what it expected - bad sequence number, etc. But then the question becomes: what is the root cause for the bad packet.
- There is an intervening firewall that decided to break the connection and inform you with an RST.
- Some failure scenarios (lost/dup packets) during connection opening.
- The operating system at the other end crashed, then restarted. When your end sends a packet, the other end sends an RST, meaning "WTF, I don't have an open connection with you."
- The TCP/IP stack ran out of buffer memory, or there was some other system level failure.
I don't know if there is some common situation that causes RST. I think, though I'm not sure, you can get an RST if you write to a socket that the peer has closed at its end. The first write() won't do it, but if you write() the peer will respond with "RST, you dummy, this connection is closed, quit writing". When this packet has arrived, further write()s get an exception. I'm not sure about this.
> - The peer received a packet that is not what it
> expected - bad sequence number, etc. But then the
> question becomes: what is the root cause for the bad
> packet.
Nope. TCP will ignore a bad sequence number and a packet with a bad TCP checksum. It won't even see a packet with a bad IP checksum.
> - There is an intervening firewall that decided to
> break the connection and inform you with an RST.
Yep.
> - Some failure scenarios (lost/dup packets) during
> connection opening.
Again no. Lost packets will be resent by the sender and duplicate packets will be ignored by the receiver. An RST is only generated during the connection phase when there is no listener at the target port.
> I don't know if there is some common situation that
> causes RST. I think, though I'm not sure, you can get
> an RST if you write to a socket that the peer has
> closed at its end. The first write() won't do it, but
> if you write() the peer will respond with "RST, you
> dummy, this connection is closed, quit writing". When
> this packet has arrived, further write()s get an
> exception. I'm not sure about this.
Quite right, and this is the most usual reason for a connection reset. It represents an application protocol error - one peer has written data that the other end isn't reading. The other most usual reason is the OS running out of buffer space locally.
> > - The peer received a packet that is not what it
> > expected - bad sequence number, etc. But then the
> > question becomes: what is the root cause for the bad
> > packet.
>
> Nope. TCP will ignore a bad sequence number and a
> packet with a bad TCP checksum. It won't even see a
> packet with a bad IP checksum.
Right you are. Somehow I was under the impression that if a sequence number is so out of whack that it can't possibly be a part of this connection, there is an RST.
Remove the words "bad sequence number, etc" from the above. RFC 793: "As a general rule, reset (RST) must be sent whenever a segment arrives which apparently is not intended for the current connection. A reset must not be sent if it is not clear that this is the case."
RFC 793: "If [...] the incoming segment acknowledges something not yet sent [...] a reset is sent." That could be what I misremembered as out-of-range sequence IDs causing RSTs.
> > - Some failure scenarios (lost/dup packets) during
> > connection opening.
>
> Again no.
I'm looking at RFC 793, "3.4 Establishing a connection". Although I don't know if those "more complex exchange[s] ... with RST's sent in both directions" show up at the API level (e.g. can accept() ever return ECONNRESET). Or am I just confused what all of that means? :-)
All that you wrote is very interesting, but I`m not sure that it can help.
In my case I have exactly "Connection reset" exception, not "Connection reset by peer" !!!
I have to say that this exception occurs after 5-10 min after creation of connection, and when client have bad connection speed with not small time of packet to arrive., so this problem occurs regularly.
Also I can note that this problem bacame more annoying when I changed streams for reading\writing
was:
new BufferedReader(new InputStreamReader(sock.getInputStream(), "UTF8"));
now:
new DataInputStream(new BufferedInputStream(socket.getInputStream()));
At this moment I even do not know what to do, because this exception kill all my work.
OK so some questions:
(1) what is at the other end?
(2) if it is Java and you have the source, does it call Socket.setSoLinger()?
(3) alternatively does this end call Socket.setSoLinger()?
(4) Is it possible that you are writing something that the other end isn't reading?