Quick detection of failed tcp connection

Question

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.

Answer 1

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?The traditional Berkeley socket API offers no way to adjust the timeout.
Some operating systems (perhaps even most major ones) have system-global settings for it - registry, /dev/somemagicname, ndd(1), etc. Google for something like windows adjust tcp timeout or solaris modify tcp retransmission or some such. Be aware that you would be setting a parameter that will affect all programs running on that system. Mostly I would just accept the 2-minute timeout; that's just the way things are.