Skip to Main Content

Java APIs

Announcement

For appeals, questions and feedback about Oracle Forums, please email oracle-forums-moderators_us@oracle.com. Technical questions should be asked in the appropriate category. Thank you!

Interested in getting your voice heard by members of the Developer Marketing team at Oracle? Check out this post for AppDev or this post for AI focus group information.

quick detection of failed tcp connection

843790Oct 9 2009 — edited Oct 9 2009
I apologize for asking this question, sense I know variants of it are asked often, but none of the standard solutions I read about seem to apply to my situation.

I have an application acting as a server for a client application written by another organization. Most of our communication is done via UDP, but the client application insists on a TCP connection which usually hangs out unused. I need to be able to detect when this TCP connection goes down. Sense I am only writing the server I can't implement a heartbeat or similar method which requires server and client to work together. Likewise doing a read and waiting for a -1 doesn’t work, as the reads seem to time out and fail even when the network is not down due to the client not sending anything to be read across the TCP connection.

So far the best solution I have come up with is to intermittently write a 0 byte when I believe there is a network error (i.e. when our udp communication stops) and capture an exception when this fails. This method does work, but I have to wait for the exception which can take 2-3 minutes from when I kill the network to occur. I would prefer for the exception to occur sooner then that if possible. I've tried setting the SO_TIMOUT bit, but sense write is usually non-blocking this doesn’t have any affect. Is there some other method of controlling how long it takes for the tcp socket to fail if it doesn’t get an ack back?

I have also thought of other methods of doing this, including always killing the TCP socket the moment UDP fails, or have my serverSocket listen for and accept any reconnect attempts, then killing the old socket once the new one is established. However both methods seem like imperfect workarounds, I would rather be able to use the absence of ACKs to detect that the TCP has stopped working.

And allow me to offer a preemptive thank you for your help.
Comments
Locked Post
New comments cannot be posted to this locked post.
Post Details
Locked on Nov 6 2009
Added on Oct 9 2009
2 comments
338 views