非阻塞connect問題
在發起一個網路連線時,如果不知道伺服器是否正常,我們經常會阻塞在connect,在《linux網路程式設計》一書中講述了使用select 實現非阻塞connect的方法,基本步驟如下:
1、建立 socket,返回套接字描述符;
2、呼叫 fcntl 或 ioctlsocket 把套介面描述符設定成非阻塞;
3、呼叫 connect 開始建立連線;
4、判斷連線是否成功建立;
5、呼叫select 等待套接安變為可讀或可寫;
6、處理超時;
7、檢查可讀或可寫條件;
8、關閉非阻塞狀態並返回;
一般情況下,這個方法會執行的很正常,但,讓我們考慮以下這種情況:
伺服器使用epoll模式接受客戶端連線,並且往一箇中心伺服器同步一些資料,當與中心伺服器通訊出現問題時,會斷開連線並使用上面的非阻塞方法重新進行連線,這時問題就出現了,如果當時客戶端連線數量大於FD_SETSIZE,並且有客戶端不斷進入,那伺服器連線中心伺服器時,建立的描述符值就可能大於FD_SETSIZE,這時使用select就會出錯,造成伺服器無法連線上中心伺服器。
在上述情況中,需要改用poll或epoll方式替代select來等待套接安變為可讀或可寫。
相關推薦
UNIX網路程式設計 非阻塞connect的實現
一、《UNIX網路程式設計》-非阻塞connect 在一個TCP套介面被設定為非阻塞之後呼叫connect,connect會立即返回EINPROGRESS錯誤,表示連線操作正在進行中,但是仍未完成;同時TCP的三路握手操作繼續進行;在這之後,我們可以呼叫select來檢查這
非阻塞connect的作用及程式碼示例
connect 函式的呼叫涉及到TCP連線的三次握手過程,通常阻塞的connect 函式會等待三次握手成功或失敗後返回,0成功,-1失敗。如果對方未響應,要隔6s,重發嘗試,可能要等待75s的嘗試並最終返回超時,才得知連線失敗。即使是一次嘗試成功,也會等待幾毫秒到幾秒的時
非阻塞connect問題
在發起一個網路連線時,如果不知道伺服器是否正常,我們經常會阻塞在connect,在《linux網路程式設計》一書中講述了使用select 實現非阻塞connect的方法,基本步驟如下: 1、建立 socket,返回套接字描述符; 2、呼叫 fcntl 或 i
系統技術非業餘研究 » 非阻塞connect的一個細節
昨天聽zhuzhaoyuan說的一個connect細節. 通常我們connect的時候都是非阻塞的, 在connect呼叫後把控制代碼掛到poll去, 等poll通知可寫的時候, 我們就認為connect成功了. 但是在linux平臺下實際上不一定成功, 具體的要用socket get_opt來檢
唯快不破:TCP網路程式設計--非阻塞accept和非阻塞connect
非阻塞accept 當一個已完成的連線準備好被accept的時候,select會把監聽socket標記為可讀。因此,如果用select等待外來的連線時,應該不需要把監聽socket設定為非阻塞模式,因為如果select告訴我們連線已經就緒,accept就不應該被阻塞。不過這樣做的時候有一個BUG:當客戶端在
UNIX網路程式設計--非阻塞connect的實現
一、《UNIX網路程式設計》-非阻塞connect 在一個TCP套介面被設定為非阻塞之後呼叫connect,connect會立即返回EINPROGRESS錯誤,表示連線操作正在進行中,但是仍未完成;同時TCP的三路握手操作繼續進行;在這之後,我們可以呼叫s
TCP之非阻塞connect和accept
套接字的預設狀態是阻塞的,這就意味著當發出一個不能立即完成的套接字呼叫時,其程序將被投入睡眠,等待響應操作完成,可能阻塞的套接字呼叫可分為以下四類: (1) 輸入操作,包括read,readv,recv,recvfrom,recvmsg; (2) 輸出操作,包括write,writev,send,sendt
【網路程式設計】非阻塞connect詳解
一、為什麼使用非阻塞connect TCP連線的建立涉及一個在三路握手過程,阻塞的connect一直等到客戶收到自己的SYN的ACK才返回,這需要至少一個RTT時間,RTT時間波動很大從幾毫秒到幾秒。而且在沒有響應時,會等待數秒再次傳送,(詳見TCPv2第828頁)
阻塞,非阻塞connect()和accept()
浪費了“黃金五年”的Java程式設計師,還有救嗎? >>>
c/c++ llinux epoll系列4 利用epoll_wait實現非阻塞的connect
llinux epoll系列4 利用epoll_wait實現非阻塞的connect connect函式是阻塞的,而且不能設定connect函式的timeout時間,所以一旦阻塞太長時間,影響使用者的體驗,所以就出來一個需求,硬要設定connect的timeout時間。 實現方法:先把connect函式變成
非阻塞模式下,雖然connect出錯,但是getsockopt取得的錯誤卻是0的問題
除錯專案程式碼時,發現了一個奇怪問題,記錄如下: 非阻塞模式下,connect發起建鏈,返回-1(這在非阻塞模式下是很正常的現象)。然後將該socket的寫事件進行監聽,在寫事件觸發後
Windows上如何玩非阻塞的connect?---讓程式設計師自定義connect函式的超時時間
我們知道, 對於阻塞的socket而言, connect函式也是阻塞的, 我在Windows上測試過, 對於阻塞的socket而言, connect的阻塞時間約為25s(linux上是75s吧, 各個平臺都不一樣). 也就是說, 很多時候, 客戶端需要等2
非阻塞套接字connect
EINPROGRESS The socket is nonblocking and the connection cannot be completed immediately. It is possible to select(2) or pol
高併發rpc時如何connect(非阻塞)
方案一:之前有設計中轉伺服器,用於轉發redis、url等訊息。 在這裡面,專門開執行緒負責套接字的連線與重連。使用阻塞等待式的方式直到連線真正連上,效率低下。程式碼如下: bool Conne
1、connect方法會阻塞,請問有什麼方法可以避免其長時間阻塞? 答:最通常的方法最有效的是加定時器;也可以採用非阻塞模式。 2、網路中,如果客戶端突然掉線或者重啟,伺服器端怎麼樣才能立刻知道? 答
3.在子網 />答: 簡: 30表示的是網路號(network number)是30位,剩下2位中11是廣播(broadcast)地址,00是multicast地址,只有01和10可以作為host address。 詳: />代表的子網的網路號是30位,即網路號是 & =,此子網的地址空間
非阻塞socket呼叫connect, epoll和select檢查連線情況示例
我們知道,linux下socket程式設計有常見的幾個系統呼叫: 對於伺服器來說, 有socket(), bind(),listen(), accept(),read(),write() 對於客戶端來說,有socket(),connect() 這裡主要要講的是客戶端
java並發編程(8)原子變量和非阻塞的同步機制
turn 判斷 變量 ntp 機制 tail values 添加 get 原子變量和非阻塞的同步機制 一、鎖的劣勢 1.在多線程下:鎖的掛起和恢復等過程存在著很大的開銷(及時現代的jvm會判斷何時使用掛起,何時自旋等待) 2.volatile:輕量級別的同步機制,
nodejs的異步非阻塞IO
nbsp png 使用 nod .com 輪詢 cnblogs 分享 strong 簡單表述一下:發啟向系統IO操作請求,系統使用線程池IO操作,執行完放到事件隊列裏,node主線程輪詢事件隊列,讀取結果與調用回調。所以說node並非真的單線程,還是使用了線程池的多線程。
(轉)異步與非阻塞之間的區別(看到的最清晰的說明)
ron 啟動 同步與異步 我們 任務 nis pro 沖突 mission Asynchronous I/O, or non-blocking I/O, is a form of input/output processing that permits other proc
Linux 設備驅動--- 阻塞型字符設備驅動 --- O_NONBLOCK --- 非阻塞標誌【轉】
ble 進程阻塞 例如 缺省 tracking 問題 href 字符驅動 調度 轉自:http://blog.csdn.net/yikai2009/article/details/8653697 版權聲明:本文為博主原創文章,未經博主允許不得轉載。 目