java - windows下socket读取超时: strange hardcode in native method

Question

我试图了解如何在 native 代码中处理套接字读取超时，并在那里发现了一些奇怪的硬编码值 5000 毫秒:

if (timeout) {
    if (timeout <= 5000 || !isRcvTimeoutSupported) {
        int ret = NET_Timeout (fd, timeout);
        .....
        .....
    }
}

来源:http://hg.openjdk.java.net/jdk8/jdk8/jdk/file/687fd7c7986d/src/windows/native/java/net/SocketInputStream.c

如我所见，变量 isRcvTimeoutSupported 通常设置为 true，但在设置套接字选项时可以将其设置为 false:

    /*
     * SO_RCVTIMEO is only supported on Microsoft's implementation
     * of Windows Sockets so if WSAENOPROTOOPT returned then
     * reset flag and timeout will be implemented using
     * select() -- see SocketInputStream.socketRead.
     */

    if (isRcvTimeoutSupported) {
        jclass iCls = (*env)->FindClass(env, "java/lang/Integer");
        jfieldID i_valueID;
        jint timeout;

        CHECK_NULL(iCls);
        i_valueID = (*env)->GetFieldID(env, iCls, "value", "I");
        CHECK_NULL(i_valueID);
        timeout = (*env)->GetIntField(env, value, i_valueID);

        /*
         * Disable SO_RCVTIMEO if timeout is <= 5 second.
         */

        if (timeout <= 5000) {
            timeout = 0;
        }


        if (setsockopt(fd, SOL_SOCKET, SO_RCVTIMEO, (char *)&timeout,
            sizeof(timeout)) < 0) {

            if (WSAGetLastError() == WSAENOPROTOOPT) {
                isRcvTimeoutSupported = JNI_FALSE;
            } else {
                NET_ThrowCurrent(env, "setsockopt SO_RCVTIMEO");
            }

        }
        ......
        ......
    }

来源:http://hg.openjdk.java.net/jdk8/jdk8/jdk/file/687fd7c7986d/src/windows/native/java/net/TwoStacksPlainSocketImpl.c

虽然我不太确定，但看起来读取超时应该在大于 5 秒时通过套接字选项设置，如果小于或等于 5 秒则通过 NET_Timeout 设置。是否正确？

不管怎样，这些硬编码的 5 秒是从哪里来的？
我在 MSDN 上没有看到任何解释。

Answer 1

此代码决定如何实现阻塞套接字超时——是使用 SO_RCVTIMEO 还是使用 select，因为 Windows 套接字都支持 (SO_RCVTIMEO 并非在所有平台上都受支持，并且如代码注释中所述，甚至并非所有 Windows 实现都支持它)。 NET_Timeout 在幕后使用 select。

基本上算法是:

if SO_RCVTIMEO is supported and timeout is more than 5 seconds:
    use SO_RCVTIMEO
else:
    use select

至于 5 秒阈值的来源，我最好的猜测是他们以某种方式发现(通过测试或反复试验？)select 对于超时值更可靠或更准确超过 5 秒。并不是说它与这个问题特别相关(它针对不同的操作系统)，而是 here is an example有人报告 SO_RCVTIMEO 对于较小的超时值不可靠。