2

I am confronted with the famous "Connection reset by peer: socket write error" issue. Here is one of its flavors.

I have two pieces of (java) software - client and server, both perfectly functional and working well for centuries all over the place. Servers are on public internet. Recently (at home) I've started to get connection drops on client side.

Client catches the reset when it tries to send something to server. This happens specifically when client runs on my home network and it sends requests with periods longer than 60 sec.

Client code if fairly basic:

socket = new Socket(address, port);
socket.setKeepAlive(true);
OutputStream os = socket.getOutputStream();

Every once in a while it does this:

os.write(bytes)

I used Wireshark to realize that connection is being forcefully dropped by "someone" and when client attempts to write, it gets the exception, handles it, re-connects and again when next request comes after longer than 60 sec, the "someone" drops the connection again. Now, I don't want to make special pinging to keep connection live.. I am 100% sure that server is not dropping anything, so it's got something to do with the idle connection.

My client is now on Windows 10, so I went ahead and modified registry KeepAliveTime value to less than 60 sec. This indeed had an affect, clients are now cool. But changing global KeepAliveTime is not a prudent solution.

I would like to understand - who is this "someone" forcefully dropping my good socket connections after precisely 60 sec? And how can I tell "him" to stop doing it, or do it less frequently.

(My environment is a typical Windows box at home behind NETGEAR router. It used to work before without issues and I guess that some of the OS updates recently started to cause this.)

Dima
  • 4,068
  • 4
  • 38
  • 47
  • Did you see an `RST` sent to the `Client` in the Wireshark? And does your `Client` do some reading from the same `Socket`? The reason why I'm asking is this: http://stackoverflow.com/questions/251243/what-causes-a-tcp-ip-reset-rst-flag-to-be-sent – ar4ers Mar 29 '17 at 10:59
  • No, client doesn't do any reading, it only connects and writes. I don't think there is RST, the Wireshark is completely silent up until Client tries to write. If previous write was less than 60 sec ago, then all is good. Longer pause - Wireshark goes red red, re-connection, etc. – Dima Mar 29 '17 at 11:16
  • @ar4ers - thanks for the link btw, interesting, I will dig in this direction although hacking routers is way beyond my expertise.. – Dima Mar 29 '17 at 11:18
  • 1.- How many connections does Server are attending at the moment of this error? 2.- What is the Time out to Read in your server and the timeout to Write in client? – Jorge Omar Medra Mar 29 '17 at 19:09
  • @JOM, 1) around 100 connections, 2) There is no way to set socket write timeouts with Java sockets, so it's irrelevant. As I said this same Server serves other Clients perfectly fine at the time of failure. The issue is on the Client side. I think.. otherwise why would fiddling with keep alive timeout in registry fixed the problem. "Someone" become happy with less than 60 sec keep alive rate and left this Client connection alone. So the question is - who is this someone? My local ISP? The router?, etc.. – Dima Mar 29 '17 at 20:55

0 Answers0