Java APIs

Socket doesn't ACK TCP packets

Please se the following image showing a CommWiev logging of a TCP session: [http://ingvild.novatron.no/TCP%20Session%2024112011_1043.PNG]

As you may see at the bottom of the logging, it ends up with the server side (right side) sending packet after packet but the Socket (left side) stops ACK'ing the packtes after some time.
Finally, the server has sent the last packet and terminates the connection with a FIN message. This FIN was however ACK'ed by the client Socket,
which indicates to me that the client Socket is still alive. If the socket had crashed for some reason it wouldn't have ACK'ed the FIN either. Correct?

I have struggeled with this problem for many days and cant find a solution or cause for the problem. I have try-catch blocks to trap Exceptions, but havnt't been able to detect anything wrong.

Brifly, what I do is to call my server (also custom written in Java) which runs fine. I won't put a link to it as it is currently mostly down for the testing. Accessing HTML-pages, images and documents with Firefox through this java-server works fine awithout problems. Also other communication works fine. The problem-conections also works fine for approx 70% of the attempts. For the rest, it hangs during somewhere during the transaction and my software finally abort and closes the Session due to timeout.

The delayed server response is due to the server waiting for data to be available (relayed from an other incoming connection). In the example I send a 0-byte every second to keep the link alive and busy. But the result is almost the same without any idle-messages. Some sessions hang halfways and others terminate as they should. I open the session early and keeps it open, mainly to save time in case of mobile connections where the time for the initial handshaking may be finished early so that the system is ready for fast response when "real" data is ready for transfer (delay for the main data transfer is the cruisial thing here). By the way, I have parallell UDP connections also for maximizing speed, but I use a double TCP/UDP connection in case i meet a firewall that doesn't let the UDP through. Ordinary http connections on port 80 will i most cases be let through, though.

The connection is kept open for up to 30 sections waiting for transfer. And from what I have read, 30 seconds shouldn't pose any problem for the TCP connection. I hva tried longer and shorter session times, but experience much the same.

So my main question now is what might cause a java Socket (built by JDK 1.6.0_29) to stop ACK'ing and behave as shown on the log? Finding the solution here is cruicial as feel very unsafe when the application seem to be so unstable. As the Java socket is widely used, I hope that someone has experienced a similar problem and may point me in the right direction. I havn't posted any program listing, but can tell that the input fetching data from the input stream is called from within at Thread running with high priority: "setPriority(Thread.NORM_PRIORITY + 3);" Also the input loop sleeps for 5ms whenever there is nothing to prosess (when inputStream.available() == 0) so that the CPU is free to do TCP processing and other stuff.

The CommWiev logging is run on my client CPU where the java client also runs. So input shown on the log has come error free through the network from the server. If something goes missing, it must be lost inside my PC between the cable connection socket that the CommWiev is monitoring and the java Socket. Has anyone experienced data getting lost internally this way?

I am also not certain if this is the correct forum or if it should have been posted on a more "narrow" network forum. If so, point med in the right direction.

Thanks for any help on this annoying problem.

Best regards
Hans Kurt Karlsen
Novatron AS