On Oct 10, 2004, at 4:33 AM, Jan Hlavat� wrote:
This is simply not true. SO_KEEPALIVE works, even for blocking in reads.
I have tested it.
Agreed. After writing the previous comments, I decided I should just go see how it works in practice. :-) After the keepalive timeout, a SocketException is thrown. (Exception in thread "main" java.net.SocketException: Operation timed out at java.net.SocketInputStream.socketRead0(Native Method))
I also tried the following (all on Mac OS X):
setting .setSoTimeout(0) along with keepalive, and the same behavior is observed. It would then appear that without a way to turn off keepalive, there's no way to specify that we want to keep the socket open indefinitely.
Also, in the case where timeout interval > keepalive interval, the keepalive timer closes the socket before the timeout value is reached. While this may not be a problem for some platforms, the default value for net.inet.tcp.keepidle on the Mac is 144s and the interval for probing is only 1.5 secs, meaning that with keepalive turned on, timeout values greater than 3 minutes would have no effect and keepalive would always close the socket at between 2 and 3 minutes. It would seem that Mac OS X is violating RFC1122, but still, that's what the value currently is on the three systems at my disposal.
So, I'm still not sure that I like having keepalive set by default without a way to turn it off. Anyway, I haven't been able to test this on other operating systems yet to see if the same behavior is true for setSoTimeout/setKeepAlive, but I'm curious if there's any difference between Linux, Solaris and Windows, so I'll get back to you on that.
andrew
