androidsocket超時

『壹』 android java怎麼設置超時時間

第一,ConnectionPoolTimeout：
定義了從ConnectionManager管理的連接池中取出連接的超時時間。
出錯會拋出

第二,ConnectionTimeout：
定義了通過網路與伺服器建立連接的超時時間，Httpclient包中通過一個非同步線程去創建與伺服器的socket連接，這就是該socket連接的超時時間。
當連接HTTP伺服器或者等待HttpConnectionManager管理的一個有效連接超時出錯會拋出ConnectionTimeoutException

第三,SocketTimeout：
這定義了Socket讀數據的超時時間，即從伺服器獲取響應數據需要等待的時間。
當讀取或者接收Socket超時會拋出SocketTimeoutException

『貳』 android中如何獲取超時時長的異常

android獲取超時時長的異常方式如下:設置超時機制
client.getParams().setIntParameter(
HttpConnectionParams.SO_TIMEOUT, TIME_OUT_DELAY); // 超時設置
client.getParams().setIntParameter(
HttpConnectionParams.CONNECTION_TIMEOUT, TIME_OUT_DELAY);// 連接超時
這里設置了兩種超時，第一種是請求超時，第二種時連接超時。
當向伺服器發出請求後，請求和伺服器建立socket連接，但是很長時間內都沒有建立socket連接，這就時第一種請求超時，這種情況主要發生在請求了
一個不存在的伺服器。超時之後，會拋出InterruptedIOException異常。
Timeout for blocking operations. The argument value is specified in
milliseconds. An InterruptedIOException is thrown if this timeout
expires.

『叄』 socket超時什麼意思

你好，這分為兩種情況。
Socket.connect連接超時有二種情況：
1.由於網路的問題，TCP/IP三次握手時間>timeout的設置時間。這在國外訪問weibo時，並且網路環境極差的情況下有可能發生。
解決的辦法：調大socket.connect方法中的timeout參數值，比如50s，linux默認最高是70s，如果超過70s沒有意義，linux會採用70s.
但是當調大之後，發現不到10s就報timeout exception。
通過國外的機器ping api.weibo.com發現unreachable。
說明客戶端在傳輸層之下的網路層就發現連個Syn的報文都發不出去，更不用說三次握手了，客戶端直接失敗並拋timeout exception。
經驗：在connection timeout診斷的第一步應該是ping一下確認網路層沒有問題。
註：客戶端設置了timeout，但並不會等到超時才返回異常。客戶端只要第一時間發現連接失敗，就會拋timeout exception。

2.如果timeout設置的時間足夠，但是由於伺服器端的處理能力較差，比如緩沖連接隊列較小，而應用層的處理能力沒有連接緩沖快，導致緩沖連接占滿，而拒絕新的連接。
在服務端因為連接隊列占滿而拒絕服務的期間，客戶端的通過TCP協議重試三次。每次的時間翻倍。
如果三次時間的累加<timeout參數值且能連接上，屬於正常情況，表示隊列騰出空位放當前連接。
如果三次時間的累加<timeout參數值且未能連接上，則客戶端會立刻拋出timeout exception,而不等timeout到期才拋。

1.讀寫超時
read超時設置有意義,在伺服器處理能力差，但最終會響應的情況下，可以將客戶端的等待響應時間設長一些。如果太長的話，由於客戶端使用的是BIO的方式，線程會一直阻塞在IO而導致掛起。當客戶端的處理能力明顯快於服務端，這樣掛起的線程會很多。
不管客戶端還是伺服器端，當有很多線程阻塞時，對機器的性能都會影響。我在weibo的論壇上看到有人在read timed out後，將soTimeout的時間設為100s。這是很危險的，新浪的伺服器一旦崩潰，自己的伺服器也會由於大量線程積壓崩潰。
因為線程在掛起之後，它掌握的資源並不會釋放，比如內存，直到阻塞完成。同時大量線程的掛起就意味著系統要做大量上下文的恢復並調度執行。
解決辦法：
如果客戶端使用NIO的方式，如果服務端的響應能標出客戶端的請求，則線程在客戶端請求之後，完全可以把請求放入一個BlockQueue，然後利用Future或Wait/Notify等機制在帶著請求標志的響應返回的時候，喚想隊列中的請求接著處理，從而實現非同步處理，可以用少量線程服務大量請求。
同樣，如果伺服器端可以使用NIO做到請求每線程處理，而不是連接每線程，可以大大減少線程掛起導致資源的浪費，NIO適用於連接很多，請求很少的場合。另外，Commet又稱為伺服器推技術，它的主要特點是長連接。避免客戶端低效的請求輪詢。主要用於聊天室，WEIBO，因為連接多，請求不一定多，同樣也適合在伺服器端使用NIO
註：read timeout異常時，並不需要ping遠程機器，因為它是輔助定位connection timeout，如果ping不通，肯定是conneciton timeout而不會到read timeout。read timeout exception不會導致連接中斷。為重試提供了機會。

2.write超時一般不象connection timeout和read timeout可以在客戶端顯示調值，TCP有寫重傳的概念，一般8m內會重試，否則，直接斷開連接。
如果對您有幫助，還望採納。

『肆』 android socket一直在鏈接 伺服器不響應

connect方法裡面:new Socket那會拋異常的。導致你上部分catch到異常。writer沒有被初始化。 接下來估計你直接使用了writer。導致了空指針異常。 所以關鍵是你的:new Socket這里。這個地方很用可能是服務端沒有打開，而導致的連接異常