java.net.Socket.setSoTimeout是否可靠？

從JavaDoc的用於setSoTimeout java.net.Socket.setSoTimeout是否可靠？

啓用與指定超時/禁用SO_TIMEOUT，以毫秒爲單位。如果將此選項設置爲非零超時，則與此套接字關聯的 InputStream上的read（）調用將僅阻止該時間量。如果超時到期，則提出一個 java.net.SocketTimeoutException異常，即，儘管Socket仍然是有效。在進入阻止操作之前必須啓用該選項才能生效。超時必須> 0。超時爲零時，將解釋爲無限超時。

從各種互聯網上的帖子我已閱讀，SO_TIMEOUT採用Socket C API（例如here）時，是相當不可靠的。

因此，這個問題是否可靠使用setSoTimeout檢查失控會話？

如果沒有，您可以推薦什麼技術來對套接字會話設置時間限制？

來源

2009-11-09 Alexander Pogrebnyak

我不知道任何相關的最近/當前操作系統，在哪個（流）套接字超時未按照它們應該工作。您鏈接的帖子來自一個相當混亂的海報，它試圖在數據報套接字上設置發送超時，這是毫無意義的。數據報或者立即發送或者放棄丟棄。

來源

2009-11-09 23:57:59 jarnbjo

+1 - 鏈接的帖子確實非常困惑。除了UDP廢話超時之外，他似乎認爲你應該能夠發送任意大的UDP數據報。 – 2009-11-10 00:05:21

查看Java 6 nio中的連接類，它們現在包括套接字，並執行非阻塞操作，因此如果您願意，可以取消操作。

Apache的htmlclient核心（？）現在能夠使用nio套接字，所以看起來他們有這個概念的工作。雖然這就是我所知道的。

來源

2009-11-09 23:12:50

但是否nio套接字可以在網絡堆棧損壞的OS上正常工作是任何人的猜測...... – 2009-11-10 00:15:38

不僅可以取消nio操作，而且Selector.select（長超時）也可以工作。 – Seth 2009-11-10 03:48:18

你能保證嗎？在具有**破損**網絡堆棧的計算機上？我會說你不能這樣做，因爲你不能認爲實現select的系統調用對於套接字來說是正確的。 – 2009-11-10 04:21:28

我不知道任何現代平臺的操作系統平臺，其網絡堆棧太破碎，套接字超時不起作用。但是如果有人知道真實生活的例子，請將其添加爲評論！

我不擔心這種情況，除非你真的被迫在這樣一個破壞的操作系統上支持你的應用程序。我懷疑這將是一個痛苦的工作。

來源

2009-11-10 00:14:00

鏈接是關於SO_RCVTIMEO。問題是關於Socket.setSoTimeout（）。在唯一的平臺上，我知道前者無法工作的地方（某些版本的Solaris），後者使用select（）方法搞定，這確實有效。該方法的合同要求它。除非有人真的想出了一個平臺，而這個平臺在16年前從未見過，否則你不必擔心這一點。

來源

2013-03-20 11:18:41 EJP

請注意，即使在Linux上，setSoTimeout也不會設置SO_RCVTIMEO選項。相反，超時值存儲在內部，JRE使用輪詢系統調用來實現讀取超時。 – 2013-12-20 17:58:13

java.net.Socket.setSoTimeout是否可靠？

回答

相關問題