Socket read timing out immediately

Question

When does the timer for SO_TIMEOUT start? Is it when you call read on the socket? Or is it after the last packet of data is received from the remote node?
In my app, I have a socket with SO_TIMEOUT set to 2 minutes. By design, the connection is idle for a period of time longer than that, but I don't even try to read from the socket during this period. Then, I write some data to the socket and try to read a response. I would expect the 2 minute interval to start when I make the blocking call to read, but instead, I get a SocketTimeoutException right away. What's going on? Was the time that the connection was purposely idle count toward the timeout interval, even though I wasn't blocked trying to read? How can I avoid this?

Answer 1

I'm now officially confused.
Digging around a bit: from the Socket FAQ:
SO_{SND,RCV}TIMEO are probably the most widely
unimplemented, or strangely/incompatibly implemented, of all
common sockopts in existence... Basically, in short, NEVER
try to use them for anything... ;-)
If you want I/O timeouts, your only real option in most cases is
to roll your own, using either blocking/alarm()-based timeouts, or
non-blocking/select()-based timeouts... The latter probably being
the best choice, and least likely to cause pain (especially if you
ever need to write multi-threaded code)...
From the JDK source (PlainSocketImpl.c):
     * SO_TIMEOUT is a no-op on Solaris/Linux
    if (cmd == java_net_SocketOptions_SO_TIMEOUT) {
        return;
    }There ya go :-)
The JDK source for Windows (PlainSocketImpl.c) sets SO_RCVTIMEO if the winsock library in question supports it. (Undocumented feature: timeouts of <= 5 seconds are interpreted as 0).
I'm starting to think maybe setSoTimeout() isn't the best thing to do... Anyone here with experience with it?