Socket InputStream.read keeps blocking dispite lost connection

Networking & Multiplayer
#1

I have a serious problem here.

Lets say I have this code on the client:


socket.getSoTimeout(4*1000);
InputStream in = socket.getInputStream();

while(true)
{
   int r = in.read();
   if(r==-1) break;
   System.out.print((char)r);
}

The socket receives data every second, so normally the timeout occurs when the connection is lost for whatever reason.

Sometimes, the TCP connection is lost (about once every 3-8 days - this is a very long lasting tcp-session!) and the server correctly notices the session is gone (IOException or a read of -1), however the client thinks it is still connected, and blocked indefinetly at read(), dispite the timeout of 4000ms! Stopping/restarting the ServerSocket at the server doesn’t help. The server sees all clients disconnect at the same time (which indicates a router reset/failure…?) and all clients are turned into zombies, blocking at read() forever, until I terminate the process of each client.

Any reason this can occur? Losing a TCP session isn’t bad, as long as I can notice this and reconnect… :-\

#2

Can you afford Thread.sleep?
You may want to do your timeout manually.

I realized that you probably don’t want to go 4 seconds without reading anything, so I updated the code snippet.

int timeout=0;
int a;
while(true) {
a = in.available();
if (a > 0) {
int r = in.read();
if (r == -1) break;
System.out.print((char)r);
tineout = 0;
} else {
Thread.sleep(0,100);
a = in.available();
if (a == 0) timeout++;
if (timeout > 40) break; // timeout
}
}

#3

Not ideal, but you could always maintain another thread keeping a reference to this one and interrupt() it in these situations?

#4

Yeah, I’m doing that right now… Another thread that monitors all TCP sessions and compares the last actual IO with the socket’s timeout value… I coded it this morning, so I’ll have to see whether it’s ‘stable’ now.

Feels like I’m doing the task the OS is supposed to do…!

#5

Well, although you’d think it should throw an Exception, it doesn’t seem like a good way to code it either. I mean, as far as the system is concerned you tell it to read(), so it blocks until it gets more data. Although it should throw an exception when the connection is lost, it is waiting like you told it to. :wink:

Would the following be an easier fix?

socket.getSoTimeout(4*1000);
InputStream in = socket.getInputStream();

while(true) {
   if (in.available() > 0) {
       int r = in.read();
       if(r==-1) break;
       System.out.print((char)r);
    }
}
#6

hum… seems that you forgot a Thread.sleep in your loop , this way cpu will burn :wink:

#7

Sorry to be a bit blunt, but that’s plain wrong.

input.read() is documented to block until either data is available, or the connection is lost - whichever happens first.

It’s just so weird that the server instantly knows the connection is lost, and the client just keeps blocking… :-\

#8

I thought about that as I was typing it up, but knew Riven knows better than to make a greedy thread so I felt it more useful to focus on the concept I was trying to convey. :stuck_out_tongue:

No, I definitely agree. I’ve experienced this myself and you’d think it would be fixed in Java by now, but perhaps there’s a good migration path to NIO. :wink:

#9

Well uh… well :slight_smile: I kinda stuck with java.io + java.net because I expected it to be extremely stable, and NIO has a bit of a rough history in that regard. I need extreme stability for this app at my work, and now I simplified the test-case to such degree that it simply can’t be my fault anymore. It’s either the JVM or the OS.

And you’re right I wouldn’t make a CPU-hungry loop…

#10

does setting
socket.setSoLinger(false,0);
have any effect? I have a client that has similar issues in that it doesn’t detect certain abnormal terminations, but it always respects the soTimeout value (at least the first one I set, doesn’t like me trying to change it)

#11

Not that you’d necessarily be interested, but you did contribute some code to JGN back in the day, and you know it’s foundation. It’s actually being used currently in a few business applications now as well (non-game) since it’s not explicitly tied to game development apart from the name. :wink: Creating an sending Message objects and adding listeners makes life pretty easy. :slight_smile:

#12

I’m not exactly sure what you’re trying to say there, but I can’t use JGN, as I’m redirecting raw traffic among servers, which is pretty much ‘send what you receive’, so there is no room for any protocol there. It just must be stable, it has to work for ever, and I hate it when it breaks down, because people rely on that silly app.

#13

Oh well, you could still make the switch to NIO. :wink:

BTW, I just wasted about 10 minutes on TinyCode:Capitalizer. :-p

boolean b = true;
int i;
while ((i = in.read()) != -1) {
char c = (char)i;
if (c == ' ') {
b = true;
} else if (b) {
if ((i > 96) && (i < 123)) c = (char)(i - 32);
b = false;
}
out.write(c);
}
#14

I think it is just a fact of life that there are four ends of every socket pair, and when connections are severed
involuntarily, the four ends can be closed independently in any order, and the clients may or may not agree
on which pipes are open and which are broken.

The only solution is to have a live ping running, with the clients closing and attempting to re-establish
communication when a timeout occurs. Depending on the underlying cause, this may or may not
be possible.

The most infuriating aspect of this is that there is no upper bound to how long a “temporary” interruption,
which will eventually be resolved without loss of data or connection, can last… A few seconds is common,
a minute is not unheard of.